1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=koi8-r">
<TITLE>Trash specification</TITLE>
<META NAME="GENERATOR" CONTENT="OpenOffice.org 1.1.0 (Linux)">
<META NAME="AUTHOR" CONTENT="Mikhail Ramendik">
<STYLE>
<!--
P.sdfootnote { margin-left: 0.5cm; text-indent: -0.5cm; margin-bottom: 0cm; font-size: 80% }
A.sdfootnoteanc { font-size: 57% }
-->
</STYLE>
</HEAD>
<BODY LANG="en-US" DIR="LTR">
<H1>The FreeDesktop.org Trash specification</H1>
<H3>Initial version written by Mikhail Ramendik <<A HREF="mailto:mr@ramendik.ru">mr@ramendik.ru</A>></H3>
<H3>Content by David Faure <<A HREF="mailto:faure@kde.org">faure@kde.org</A>>,
Alexander Larsson <<A HREF="mailto:alexl@redhat.com">alexl@redhat.com</A>>,
Ryan Lortie <<A HREF="mailto:desrt@desrt.ca">desrt@desrt.ca</A>>
and others on the FreeDesktop.org mailing list</H3>
<H3>Version 1.0</H3>
<H2>Abstract</H2>
<P>The purpose of this Specification is to provide a common way in
which all “Trash can” implementations should store, list,
and undelete trashed files. By complying with this Specification,
various Trash implementations will be able to work with the same
devices and use the same Trash storage. For example, if one
implementation sends a file into the Trash can, another will be able
to list it, undelete it, or clear it from the Trash.</P>
<H2>Introduction</H2>
<P>An ability to recover accidentally deleted files has become the de
facto standard for today's desktop user experience.
</P>
<P>Users do not expect that anything they delete is permanently gone.
Instead, they are used to a “Trash can” metaphor. A
deleted document ends up in a “Trash can”, and stays
there at least for some time — until the can is manually or
automatically cleaned.
</P>
<P>This system has its own problems. Notably, cleaning disk space
becomes a two-step operation — delete files and empty trash;
this can lead to confusion for inexperienced users (“what's
taking up my space?!”). Also, it is not easy to adapt the
system to a multiuser environment. Besides, there is a potential for
abuse by uneducated users — anecdotal evidence says they
sometimes store important documents in the Trash can, and lose them
when it gets cleaned!</P>
<P>However, the benefits of this system are so great, and the user
expectation for it so high, that it definitely should be implemented
on a free desktop system. And in fact, several implementations
existed before this specification — some as command line utilities, some as
preloaded libraries, and some as parts of major desktop environments.
For example, both Gnome and KDE had their own trash mechanisms.</P>
<P>This Specification is to provide a common way in which all Trash
can implementations must store trashed files. By complying with
this Specification, various Trash implementations will be able to
work with the same devices and use the same Trash storage.
</P>
<P>This ability is important, at least, for shared network resources,
removable devices, and in cases when different implementations are
used on the same machine at different moments (for example, some users prefer
Gnome, others prefer KDE, and yet others are command-line fans).</P>
<H2>Scope and limitations</H2>
<P>This Specification only describes the Trash storage. It does <B>not</B>
limit the ways in which the actual implementations should operate, as
long as they use the same Trash storage. Command line utilities,
desktop-integrated solutions and preloaded libraries can work with
this specification. <A CLASS="sdfootnoteanc" NAME="sdfootnote1anc" HREF="#sdfootnote1sym"><SUP>1</SUP></A></P>
<P>This Specification is geared towards the Unix file system tree
approach. However, with slight modifications, it can easily be used
with another kind of file system tree (for example, with drive
letters).
</P>
<P>A multi-user environment, where users have specific numeric
identifiers, is essential for this Specification.
</P>
<P>File systems and logon systems can be
case-sensitive or non-case-sensitive; therefore, systems should
generally not allow user names that differ only in case.</P>
<H2>Definitions</H2>
<P>Trash, or Trash can — the storage of files that were trashed
(“deleted”) by the user. These files can be listed,
undeleted, or cleaned from the trash can.</P>
<P>Trashing — a “delete” operation in which files
are transferred into the Trash can.</P>
<P>Erasing — an operation in which files (possibly already in
the Trash can) are removed (unlinked) from the file system. An erased
file is generally considered to be non-recoverable; the space used by
this file is freed. [A “shredding” operation, physically
overwriting the data, may or may not accompany an erasing operation;
the question of shredding is beyond the scope of this document].</P>
<P>Original location — the name and location that a file
(currently in the trash) had prior to getting trashed.</P>
<P>Original filename — the name that a file (currently in the
trash) had prior to getting trashed.
</P>
<P>Top directory , $topdir — the directory where a file system
is mounted. “/” is the top directory for the root file
system, but not for the other mounted file systems. For example,
separate file systems might be mounted on “/home”, “/media/flash”,
etc. In this text, the designation “$topdir” is used for
“any top directory”.</P>
<P>User identifier , $uid — the numeric user identifier for a
user. $uid is used here as “the numeric user identifier of the
user who is currently logged on”.</P>
<P>Trash directory — a directory where trashed files, as well
as the information on their original name/location and time of
trashing, are stored. There may be several trash directories on one
system; this Specification defines their location and contents. In
this text, the designation “$trash” is used for “any
trash directory”.</P>
<P>“Home trash” directory — a user's main trash
directory. Its name and location is defined in this document.</P>
<P>The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in <A HREF="http://www.faqs.org/rfcs/rfc2119.html">RFC
2119</A>.</P>
<H2>Trash directories</H2>
<P>A system can have one or more trash directories. The contents of
any trash directory are to be compliant with the same standard,
described below.</P>
<P>For every user<A CLASS="sdfootnoteanc" NAME="sdfootnote2anc" HREF="#sdfootnote2sym"><SUP>2</SUP></A>
a “home trash” directory MUST be available.
Its name and location are $XDG_DATA_HOME/Trash <A CLASS="sdfootnoteanc" NAME="sdfootnote3anc" HREF="#sdfootnote3sym"><SUP>3</SUP></A>; $XDG_DATA_HOME is
the base directory for user-specific data, as defined in the <A HREF="http://www.freedesktop.org/Standards/basedir-spec">Desktop
Base Directory Specification</A> .
</P>
<P>The “home trash” SHOULD function as the user's main
trash directory. Files that the user trashes from the same file
system (device/partition) SHOULD be stored here (see the next section
for the storage details). A “home trash” directory SHOULD
be automatically created for any new user. If this directory is
needed for a trashing operation but does not exist, the
implementation SHOULD automatically create it, without any warnings
or delays.</P>
<P>The implementation MAY also support trashing files from the rest
of the system (including other partitions, shared network resources,
and removable devices) into the “home trash” directory .
This is a “failsafe” method: trashing works for all file
locations, the user can not fill up any space except the home
directory, and as other users generally do not have access to it, no
security issues arise.</P>
<P>However, this solution leads to costly file copying (between
partitions, over the network, from a removable device, etc.) A delay
instead of a quick “delete” operation can be unpleasant
to users.</P>
<P>An implementation MAY choose not to support trashing in some of
these cases (notably on network resources and removable devices).
This is what some well known operating systems do.</P>
<P>It MAY also choose to provide trashing in the “top
directories” of some or all mounted resources. This trashing is
done in two ways, described below as (1) and (2).
</P>
<P>(1) An administrator can create an $topdir/.Trash directory. The
permissions on this directories should permit all users who can trash
files at all to write in it.; and the “sticky bit” in the
permissions must be set, if the file system supports it.
</P>
<P>When trashing a file from a non-home partition/device<A CLASS="sdfootnoteanc" NAME="sdfootnote4anc" HREF="#sdfootnote4sym"><SUP>4</SUP></A>
, an implementation (if it supports trashing in top directories) MUST
check for the presence of $topdir/.Trash.</P>
<P>When preparing a list of all trashed files (for example, to show to the
user), an implementation also MUST check for .Trash in all top
directories that are known to it.</P>
<P>If this directory is present, the implementation MUST, by default,
check for the “sticky bit”. (It MAY provide a way for the
administrator, <I>and only the administrator</I>, to disable this
checking for a particular top directory, in order to support file
systems that do not have the “sticky bit”).</P>
<P>The implementation also MUST check that
this directory is not a symbolic link.
</P>
<P>If any of these checks fail, the
implementation MUST NOT use this directory for either trashing or
undeleting files, even if an appropriate $uid directory (see below)
already exists in it. Besides, the implementation SHOULD report the
failed check to the administrator, and MAY also report it to the
user.</P>
<P>The following paragraph applies ONLY to
the case when the implementation supports trashing in the top
directory, and a $topdir/.Trash exists and has passed the checks:</P>
<P STYLE="margin-left: 2cm">If the directory exists and passes the
checks, a subdirectory of the $topdir/.Trash directory is to be used
as the user's trash directory for this partition/device. The name of
this subdirectory is the numeric identifier of the current user
($topdir/.Trash/$uid). When trashing a file, if this directory does
not exist for the current user, the implementation MUST immediately
create it, without any warnings or delays for the user.</P>
<P>(2) If an $topdir/.Trash directory is
absent, an $topdir/.Trash-$uid directory is to be used as the user's
trash directory for this device/partition. $uid is the user's numeric
identifier.</P>
<P>The following paragraph applies ONLY to
the case when the implementation supports trashing in the top
directory, and a $topdir/.Trash does not exist or has not passed the
checks:</P>
<P STYLE="margin-left: 2cm">When trashing a file,
if an $topdir/.Trash-$uid directory does not exist, the
implementation MUST immediately create it, without any warnings or
delays for the user.</P>
<P>When trashing a file, if this directory
does not exist for the current user, the implementation MUST
immediately create it, without any warnings or delays for the user.</P>
<P><B>Notes.</B> If an implementation provides trashing in top
directories at all, it MUST support both (1) and (2).
</P>
<P>If an implementation does NOT provide trashing in top directories, and does
provide the user with some interface to view and/or undelete trashed
files, it SHOULD make a “best effort” to show files
trashed in top directories (by both methods) to the user, among other
trashed files or in a clearly accessible separate way.</P>
<P>When trashing a file, if the method (1) fails at any point —
that is, the $topdir/.Trash directory does not exist, or it fails the
checks, or the system refuses to create an $uid directory in it —
the implementation MUST, by default, fall back to method (2),
described below. Except for the case when $topdir/.Trash fails the
checks, the fallback must be immediate, without any warnings or
delays. The implementation MAY, however, provide a way for the administrator
to disable (2) completely.</P>
<P>If both (1) and (2) fail (that is, no
$topdir/.Trash directory exists, and an attempt to create
$topdir/.Trash-$uid fails), the implementation MUST either trash the
file into the user's “home trash” or refuse to trash it.
The choice between these options can be pre-determined, or it can
depend on the particular situation (for example, “no trashing of very large
files”). However, if an implementation refuses to trash a file after a
user action that generally causes trashing, it MUST clearly warn the
user that the trashing has failed. It MUST NOT erase the file without user confirmation.</P>
<P>For showing trashed files, implementations SHOULD support (1) and
(2) at the same time (that is, if both $topdir/.Trash/$uid and
$topdir/.Trash-$uid are present, it should list trashed files from
both of them).</P>
<H2>Contents of a trash directory</H2>
<P>The previous section has described the location of trash
directories. This section concerns the contents of any trash
directory (including the “home trash” directory). This
trash directory will be named “$trash” here.</P>
<P>A trash directory contains two subdirectories, named <B>info</B> and
<B>files</B>.</P>
<P>The <B>$trash/files</B> directory contains the files and
directories that were trashed. When a file or directory is trashed,
it MUST be moved into this directory<A CLASS="sdfootnoteanc" NAME="sdfootnote5anc" HREF="#sdfootnote5sym"><SUP>5</SUP></A>
. The names of files in this directory are to be determined by the
implementation; the only limitation is that they must be unique
within the directory. <I>Even if a file with the same name and
location gets trashed many times, each subsequent trashing must not
overwrite a previous copy. </I>The access rights, access time,
modification time and extended attributes (if any) for a
file/directory in $trash/files SHOULD be the same as the
file/directory had before getting trashed.</P>
<P><B>IMPORTANT NOTE. While an implementation may choose to base
filenames in the $trash/files directory on the original filenames,
this is never to be taken for granted<A CLASS="sdfootnoteanc" NAME="sdfootnote6anc" HREF="#sdfootnote6sym"><SUP>6</SUP></A>.
A filename in the $trash/files directory MUST NEVER be used to
recover the original filename; use the info file (see below) for
that. </B>(If an info file corresponding to a file/directory in
$trash/files is not available, this is an emergency case, and MUST be
clearly presented as such to the user or to the system
administrator).
</P>
<P>The <B>$trash/info </B>directory contains an “information
file” for every file and directory in $trash/files. This file
MUST have exactly the same name as the file or directory in
$trash/files, plus the extension “.trashinfo”<A CLASS="sdfootnoteanc" NAME="sdfootnote7anc" HREF="#sdfootnote7sym"><SUP>7</SUP></A>.
</P>
<P>The format of this file is similar to the format of a desktop
entry file, as described in the <A HREF="http://www.freedesktop.org/Standards/desktop-entry-spec">Desktop
Entry Specification</A> . Its first line must be [Trash Info].
</P>
<P>It also must have two lines that are
key/value pairs as described in the Desktop Entry Specification:</P>
<UL>
<LI><P>The key “Path”
contains the original location of the file/directory, as either an
absolute pathname (starting with the slash character “/”)
or a relative pathname (starting with any other character). A
relative pathname is to be from the directory in which the trash
directory resides (for example, from $XDG_DATA_HOME for the “home
trash” directory); it MUST not include a “..”
directory, and for files not “under” that directory,
absolute pathnames must be used. The system SHOULD support
absolute pathnames only in the “home trash” directory, not in
the directories under $topdir.
</P>
<P>The value type for this key is
“string”; it SHOULD store the file name as the
sequence of bytes produced by the file system, with characters escaped
as in URLs (as defined by <A HREF="http://www.faqs.org/rfcs/rfc2396.html">RFC
2396</A>, section 2).</P>
<LI><P>The key “DeletionDate” contains
the date and time when the file/directory was trashed. The date and
time are to be in the YYYY-MM-DDThh:mm:ss
format (see <A HREF="http://www.faqs.org/rfcs/rfc3339.html">RFC
3339</A>). The time zone should be the user's (or
filesystem's) local time. The value type for this key is “string”.</P>
</UL>
<P>Example:</P>
<PRE>[Trash Info]
Path=foo/bar/meow.bow-wow
DeletionDate=20040831T22:32:08</PRE><P>
The implementation MUST ignore any other lines in this file, except
the first line (must be [Trash Info]) and these two key/value pairs.
If a string that starts with “Path=” or “DeletionDate=”
occurs several times, the first occurence is to be used.<A CLASS="sdfootnoteanc" NAME="sdfootnote8anc" HREF="#sdfootnote8sym"><SUP>8</SUP></A></P>
<P>Note that $trash/info has no subdirectories. For a directory in
$trash/files, only an information file for its own name is needed.
This is because, when a subdirectory gets trashed, it must be moved
to $trash/files with its entire contents. The names of the files and
directories within the directory MUST NOT be altered; the
implementation also SHOULD preserve the access and modification time
for them.</P>
<P>When trashing a file or directory, the implementation MUST create
the corresponding file in $trash/info first. Moreover, it MUST try to do this in an atomic
fashion, so that if two processes try to trash files with the same
filename this will result in two different trash files. On Unix-line
systems this is done by generating a filename, and then opening with
O_EXCL. If that succeeds the creation was atomic (at least on the
same machine), if it fails you need to pick another filename.</P>
<H2>Directory size cache</H2>
<P>In order to speed up the calculation of the total size of a particular trash directory,
implementations (since version 1.0 of this specification) SHOULD create or update the
<B>$trash/directorysizes</B> file, which is a cache of the sizes of the directories
that were trashed into this trash directory.
Individual trashed files are not present in this cache, since their size can be determined
with a call to stat().</P>
<P>Each entry contains the name and size of the trashed directory, as well as the modification
time of the corresponding <B>trashinfo file</B> (IMPORTANT: not the modification time of the directory itself)<A CLASS="sdfootnoteanc" NAME="sdfootnote9anc" HREF="#sdfootnote9sym"><SUP>9</SUP></A>.</P>
<P>The size is calculated as the disk space used by the directory and its
contents, that is, the size of the blocks, in bytes (in the same way as the `du -B1` command calculates).</P>
<P>The modification time is stored as an integer, the number of seconds since Epoch. Implementations SHOULD use at least 64 bits for this number in memory.</P>
<P>The “directorysizes” file has a simple text-based format, where each line is:</P>
<PRE>
[size] [mtime] [percent-encoded-directory-name]
</PRE>
<P>Example:</P>
<PRE>
16384 15803468 Documents
8192 15803582 Another_Folder
</PRE>
<P>The last entry on each line is the name of the trashed directory, stored as the
sequence of bytes produced by the file system, with characters escaped
as in URLs (as defined by <A HREF="http://www.faqs.org/rfcs/rfc2396.html">RFC 2396</A>, section 2).
Strictly speaking, percent-encoding is really only necessary for the newline character and for '%' itself.
However, encoding all control characters or fully applying RFC 2396 for consistency with trashinfo files
is perfectly valid, and even if an implementation does not use such encoding. it MUST be able to read names encoded with it.</P>
<P>The character '/' is not allowed in the directory name (even as %2F), since all these
directories must be direct children of the "files" directory. Absolute paths are not allowed for the same reason.</P>
<P>To update the directorysizes file, implementations MUST use a temporary file followed by an atomic rename() operation, in order
to avoid corruption due to two implementations writing to the file at the same time. The fact
that the changes from one of the writers could get lost isn't an issue, as the cache can be updated again
later on to add that entry.</P>
<H2>Non-normative: suggested algorithm for calculating the size of a trash directory</H2>
<PRE>
load directorysizes file into memory as a hash directory_name -> (size, mtime, seen=false)
totalsize = 0
list "files" directory, and for each item:
stat the item
if a file:
totalsize += file size
if a directory:
stat the trashinfo file to get its mtime
lookup entry in hash
if no entry found or entry's cached mtime != trashinfo's mtime:
calculate directory size (from disk)
totalsize += calculated size
add/update entry in hash (size of directory, trashinfo's mtime, seen=true)
else:
totalsize += entry's cached size
update entry in hash to set seen=true
done
remove entries from hash which have (seen == false)
write out hash back to directorysizes file
</PRE>
<H2>Implementation notes</H2>
<P>The names of the files/directories in $trash/info SHOULD be
somehow related to original file names. This can help manual recovery
in emergency cases (for example, if the corresponding info file is
lost).</P>
<P>When trashing a file or directory, the implementation SHOULD check
whether the user has the necessary permissions to delete it, before
starting the trashing operation itself.</P>
<P>When copying, rather than moving, a file into the trash (when
trashing to the “home trash” from a different partition),
exact preservation of permissions might be impossible. Notably, a
file/directory that was owned by another user will now be owned by
this user (changing owners is usually only available to root). This
SHOULD NOT cause the trashing operation to fail.</P>
<P>In this same situation, setting the permissions should be done
<I>after</I> writing the copied file, as they might make it
unwriteable..</P>
<P>A trashing operation might be refused because of insufficient
permissions, even when the user does have the right to delete a file
or directory. This may happen when the user has the right to delete a
file/directory, but not to read it (or, in the case of a directory,
to list it). In this case, the best solution is probably to warn the
user, offering options to delete the file/directory or leave it
alone. As noted earlier, when the user reasonably expects a file to be
trashed, the implementation MUST NOT delete it without warning the user.
</P>
<P>Automatic trash cleaning may, and probably eventually should, be
implemented. But the implementation should be somehow known to the
user.</P>
<P>If a directory was trashed in its entirety, it is easiest to
undelete it or remove it from the trash only in its entirety as well,
not as separate files. The user might not have the permissions to
delete some files in it even while he does have the permission to
delete the directory!</P>
<P><B>Important note on scope</B>. This specification currently does
NOT define trashing on remote machines where multiuser permissions
are implemented but the numeric user ID is not supported, like FTP
sites and CIFS shares. In systems implementing this specification,
trashing of files from such machines is to be done only to the user's
home trash directory (if at all). A future version may address this
limitation.</P>
<H2>Administrativia</H2>
<H3>Copyright and License</H3>
<P>Copyright (C) 2004-2014 Mikhail Ramendik , <A HREF="mailto:mr@ramendik.ru">mr@ramendik.ru</A>
.
</P>
<P>The originators of the ideas that are described here did not
object to this copyright. The author is ready to transfer the
copyright to a standards body that would be committed to keeping this
specification, or any successor to it, an open standard.</P>
<P>The license: Use and distribute as you wish. If you make a
modified version and redistribute it, (a) keep the name of the author
and contributors somewhere, and (b) indicate that this is a modified
version.</P>
<P>Implementation under any license at all is explicitly allowed.</P>
<H3>Location</H3>
<P><A HREF="http://standards.freedesktop.org/trash-spec/trashspec-latest.html">http://standards.freedesktop.org/trash-spec/trashspec-latest.html</A>
.</P>
<H3>Version history</H3>
<P>0.1 “First try”, August 30, 2004. Initial draft.
“Implementation notes” not written as yet.</P>
<P>0.2 August 30, 2004. Updated with feedback by Alexander Larsson
<<A HREF="mailto:alexl@redhat.com">alexl@redhat.com</A>> and by
Dave Cridland <<A HREF="mailto:dave@cridland.net">dave@cridland.net</A>></P>
<P>0.3 September 8, 2004. Changed the name and location of the “home
trash” directory, and introduced the generic term “home
trash”. Changed the trash info file format to a .desktop-like
one. Added directions on creation of info files and copying of
trashed files. Changed user names to user ids. Added implementation
notes. Added a copyright notice.</P>
<P>0.4 September 9, 2004. Changed [Trash entry] to [Trash info] and
fixed some typo's</P>
<P>0.5 September 9, 2004. Changed [Trash info] to [Trash Info]</P>
<P>0.6 October 8, 2004. Corrections by Alexander Larsson
<<A HREF="mailto:alexl@redhat.com">alexl@redhat.com</A>> . Also
added “note on scope”. Cleaned up HTML. Added a link to this
document on the freedesktop.org standards page</P>
<P>0.7 April 12, 2005. Added URL-style encoding for the name of the deleted file,
as implemented in KDE 3.4</P>
<P>0.8 March 14, 2012. Update David Faure's email address, fix permanent URL for this spec.</P>
<P>1.0 January 2, 2014. Add directorysizes cache; style review.</p>
<P><BR><BR>
</P>
<DIV ID="sdfootnote1">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote1sym" HREF="#sdfootnote1anc">1</A>However,
developers of preloaded libraries should somehow work around the
case when a desktop environment also supporting the Trash
specification is run on top of them. “Double trashing”
and “trashing of the trash” should be avoided.</P>
</DIV>
<DIV ID="sdfootnote2">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote2sym" HREF="#sdfootnote2anc">2</A>To
be more precise, for every user who can use the trash facility. In
general, all human users, and possibly some “robotic”
ones like ftp, should be able to use the trash facility.
</P>
</DIV>
<DIV ID="sdfootnote3">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote3sym" HREF="#sdfootnote3anc">3</A>For
case sensitive file systems, note the case.</P>
</DIV>
<DIV ID="sdfootnote4">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote4sym" HREF="#sdfootnote4anc">4</A>To
be more precise, from a partition/device different from the one on
which $XDG_DATA_HOME resides.
</P>
</DIV>
<DIV ID="sdfootnote5">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote5sym" HREF="#sdfootnote5anc">5</A>“$trash/files/”,
<B>not </B>into “$trash/” as in many existing
implementations!</P>
</DIV>
<DIV ID="sdfootnote6">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote6sym" HREF="#sdfootnote6anc">6</A>At
least because another implementation might trash files into the same
trash directory</P>
</DIV>
<DIV ID="sdfootnote7">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote7sym" HREF="#sdfootnote7anc">7</A>For
example, if the file in $trash/files is named foo.bar , the
corresponding file in $trash/info MUST be named foo.bar.trashinfo</P>
</DIV>
<DIV ID="sdfootnote8">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote8sym" HREF="#sdfootnote8anc">8</A>This
provides for future extension</P>
</DIV>
<DIV ID="sdfootnote9">
<P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote9sym" HREF="#sdfootnote9anc">9</A>Rationale:
if an older trash implementation restores a trashed directory, adds files to a nested subdir and trashes it again,
the modification time of the directoy didn't change, so it is not a good indicator. However the modification time
of the trashinfo file will have changed, since it is always the time of the actual trashing operation.</P>
</DIV>
</BODY>
</HTML>
|