summaryrefslogtreecommitdiffstats
path: root/trash
diff options
context:
space:
mode:
Diffstat (limited to 'trash')
-rw-r--r--trash/trashspec.html457
1 files changed, 457 insertions, 0 deletions
diff --git a/trash/trashspec.html b/trash/trashspec.html
new file mode 100644
index 0000000..0950084
--- /dev/null
+++ b/trash/trashspec.html
@@ -0,0 +1,457 @@
+<!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>Written by Mikhail Ramendik &lt;<A HREF="mailto:mr@ramendik.ru">mr@ramendik.ru</A>&gt;</H3>
+<H3>Content by David Faure &lt;<A HREF="mailto:faure@kde.org">faure@kde.org</A>&gt;,
+Alexander Larsson &lt;<A HREF="mailto:alexl@redhat.com">alexl@redhat.com</A>&gt;
+and others on the FreeDesktop.org mailing list</H3>
+<H3>Version 0.7</H3>
+<H2>Abstract</H2>
+<P>The purpose of this Specification is to provide a common way in
+which all &ldquo;Trash can&rdquo; 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 &ldquo;Trash can&rdquo; metaphor. A
+deleted document ends up in a &ldquo;Trash can&rdquo;, and stays
+there at least for some time &mdash; 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 &mdash; delete files and empty trash;
+this can lead to confusion for inexperienced users (&ldquo;what's
+taking up my space?!&rdquo;). Also, it is not easy to adapt the
+system to a multiuser environment. Besides, there is a potential for
+abuse by uneducated users &mdash; 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
+already exist &mdash; some as command line utilities, some as
+preloaded libraries, and some as parts of major desktop environments.
+For example, both Gnome and KDE have their own trash mechanisms.</P>
+<P>This Specification is to provide a common way in which all Trash
+can implementations should 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 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 (i.e. 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 &mdash; the storage of files that were trashed
+(&ldquo;deleted&rdquo;) by the user. These files can be listed,
+undeleted, or cleaned from the trash can.</P>
+<P>Trashing &mdash; a &ldquo;delete&rdquo; operation in which files
+are transferred into the Trash can.</P>
+<P>Erasing &mdash; 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 &ldquo;shredding&rdquo; 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 &mdash; the name and location that a file
+(currently in the trash) had prior to getting trashed.</P>
+<P>Original filename &mdash; the name that a file (currently in the
+trash) had prior to getting trashed.
+</P>
+<P>Top directory , $topdir &mdash; the directory where a file system
+is mounted. &ldquo;/&rdquo; is the top directory for the root file
+system, but not for the other mounted file systems. For example,
+separate FSes can be mounted on &ldquo;/home&rdquo;, &ldquo;/mnt/flash&rdquo;,
+etc. In this text, the designation &ldquo;$topdir&rdquo; is used for
+&ldquo;any top directory&rdquo;.</P>
+<P>User identifier , $uid &mdash; the numeric user identifier for a
+user. $uid is used here as &ldquo;the numeric user identifier of the
+user who is currently logged on&rdquo;.</P>
+<P>Trash directory &mdash; 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 &ldquo;$trash&rdquo; is used for &ldquo;any
+trash directory&rdquo;.</P>
+<P>&ldquo;Home trash&rdquo; directory &mdash; a user's main trash
+directory. Its name and location is defined in this document.</P>
+<P>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;,
+&quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD
+NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot;
+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 &ldquo;home trash&rdquo; directory MUST be available<A CLASS="sdfootnoteanc" NAME="sdfootnote3anc" HREF="#sdfootnote3sym"><SUP>3</SUP></A>.
+Its name and location are $XDG_DATA_HOME/Trash ; $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 &ldquo;home trash&rdquo; 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 &ldquo;home trash&rdquo; 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 &ldquo;home trash&rdquo; directory .
+This is a &ldquo;failsafe&rdquo; 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 &ldquo;delete&rdquo; 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 &ldquo;top
+directories&rdquo; 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 &ldquo;sticky bit&rdquo; 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 (i.e. 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 &ldquo;sticky bit&rdquo;. (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 &ldquo;sticky bit&rdquo;).</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 is 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 such trashing, and does
+provide the user with some interface to view and/or undelete trashed
+files, it SHOULD make a &ldquo;best effort&rdquo; 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 &mdash;
+i.e. the $topdir/.Trash directory does not exist, or it fails the
+checks, or the system refuses to create an $uid directory in it &mdash;
+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, a way for the administrator
+to disable (2) completely.</P>
+<P>If both (1) and (2) fail (i.e. 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 &ldquo;home trash&rdquo; or refuse to trash it.
+The choice between these options can be pre-determined, or it can
+depend on the particular situation (i.e. 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 about this, and request confirmation for the action.</P>
+<P>For showing trashed files, implementations SHOULD support (1) and
+(2) at the same time (i.e. 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 &ldquo;home trash&rdquo; directory). This
+trash directory will be named &ldquo;$trash&rdquo; 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 &ldquo;information
+file&rdquo; 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 &ldquo;.trashinfo&rdquo;<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 &ldquo;Path&rdquo;
+ contains the original location of the file/directory, as either an
+ absolute pathname (starting with the slash character &ldquo;/&rdquo;)
+ or a relative pathname (starting with any other character). A
+ relative pathname is to be from the directory in which the trash
+ directory resides (i.e., from $XDG_DATA_HOME for the &ldquo;home
+ trash&rdquo; directory); it MUST not include a &ldquo;..&rdquo;
+ directory, and for files not &ldquo;under&rdquo; that directory,
+ absolute pathnames must be used. The system SHOULD only support
+ absolute pathnames in the &ldquo;home trash&rdquo; directory, not in
+ the directories under $topdir.
+ </P>
+ <P>The value type for this key is
+ &ldquo;string&rdquo;; 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 &ldquo;DeletionDate&rdquo; 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 &ldquo;string&rdquo;.</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 &ldquo;Path=&rdquo; or &ldquo;DeletionDate=&rdquo;
+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. When trashing a file or
+directory, the implementation MUST create thecorresponding file in
+$trash/info first. Moreover, it MUST try to do this in an atomic
+fashion, so that if two processes try 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>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 (i.e. When
+trashing to the &ldquo;home trash&rdquo; 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 may 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.</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>Status of this document</H3>
+<P>This document is, at this moment, only a draft. It will hopefully
+become an official or semi-official FreeDesktop.org specification in
+the future.</P>
+<P>Date of first public distribution: August 30, 2004. This document
+will serve as evidence of prior art for any patent filed after this
+date.</P>
+<H3>Copyright and License</H3>
+<P>Copyright (C) 2004 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://www.ramendik.ru/docs/trashspec.html">http://www.ramendik.ru/docs/trashspec.html</A>
+. If this document gets hosted by FreeDesktop.org, a link to the page
+will still be available at this location.</P>
+<P><A HREF="http://www.ramendik.ru/docs/trashspec.0.7.html">http://www.ramendik.ru/docs/trashspec.0.7.html</A>
+is the permanent location of this version.
+</P>
+<H3>Version history</H3>
+<P>0.1 &ldquo;First try&rdquo;, August 30, 2004. Initial draft.
+&ldquo;Implementation notes&rdquo; not written as yet.</P>
+<P>0.2 August 30, 2004. Updated with feedback by Alexander Larsson
+&lt;<A HREF="mailto:alexl@redhat.com">alexl@redhat.com</A>&gt; and by
+Dave Cridland &lt;<A HREF="mailto:dave@cridland.net">dave@cridland.net</A>&gt;</P>
+<P>0.3 September 8, 2004. Changed the name and location of the &ldquo;home
+trash&rdquo; directory, and introduced the generic term &ldquo;home
+trash&rdquo;. 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
+&lt;<A HREF="mailto:alexl@redhat.com">alexl@redhat.com</A>&gt; . Also
+added &ldquo;note on scope&rdquo;. 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><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. &ldquo;Double trashing&rdquo;
+ and &ldquo;trashing of the trash&rdquo; 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 &ldquo;robotic&rdquo;
+ 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>Note
+ the dot in the beginning, and 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>&ldquo;$trash/files/&rdquo;,
+ <B>not </B>into &ldquo;$trash/&rdquo; 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>
+</BODY>
+</HTML>