diff options
| author | David Faure <faure@kde.org> | 2012-03-14 15:37:06 +0100 |
|---|---|---|
| committer | David Faure <faure@kde.org> | 2012-03-14 16:28:30 +0100 |
| commit | 661f6e946f6868c709b9f94c2cabb2d340263885 (patch) | |
| tree | 5f0c4d6f0b82d320bba52b9a6ad32aabf649d7bb | |
| parent | fc78555ec5f11c4df61b97138a41686cb9d1bdb1 (diff) | |
| download | xdg-specs-661f6e946f6868c709b9f94c2cabb2d340263885.tar.xz | |
trash: Import version 0.1 of the trash spec.
| -rw-r--r-- | trash/trashspec.html | 497 |
1 files changed, 165 insertions, 332 deletions
diff --git a/trash/trashspec.html b/trash/trashspec.html index 0950084..b2ad642 100644 --- a/trash/trashspec.html +++ b/trash/trashspec.html @@ -1,146 +1,139 @@ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD> - <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=koi8-r"> + <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=us-ascii"> <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% } + P.sdfootnote { margin-left: 0.5cm; text-indent: -0.5cm; margin-bottom: 0cm; font-size: 10pt } 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 <<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>>, +<H3><SPAN>By Mikhail Ramendik <<A HREF="mailto:mr@ramendik.ru">mr@ramendik.ru</A>></SPAN></H3> +<H3>Version 0.1 “First Try”</H3> +<H4>Based on network discussion by David Faure +<<A HREF="mailto:dfaure@trolltech.com">dfaure@trolltech.com</A>>, Alexander Larsson <<A HREF="mailto:alexl@redhat.com">alexl@redhat.com</A>> -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 “Trash can” implementations should store, list, +and others on the FreeDesktop.org mailing list.</H4> +<H2>Overview</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 already exist – 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>The purpose of this Specification is to provide a +common way in which all Trash can implementation 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 -already exist — 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> +<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>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>A multi-user environment, +where users have specific alphanumeric names, 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> +<P LANG="en-US" STYLE="font-weight: medium">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 +<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 +<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 +<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 +<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 +<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 +<P>Top directory – 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 FSes can be mounted on “/home”, “/mnt/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 +<P>Home directory – the “home” directory for a +user; the user generally stores personal fines in this folder. Also +known as $HOME. In Unix-like systems, home directories are usually +located under the /home or /usr/home tree .</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> +<P>MUST – an +implementation has to do this in order to be in compliance with this +Specification.</P> +<P>SHOULD – doing this +is recommended, but not required.</P> +<P>MAY – doing this is +optional.</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<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 “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> +a <B>$HOME/.Trash</B> directory MUST be available<A CLASS="sdfootnoteanc" NAME="sdfootnote3anc" HREF="#sdfootnote3sym"><SUP>3</SUP></A>. +It should function as the user's Trash directory. Files that the user +trashes from the home directory should be stored here (see the next +section for the storage details). $HOME/.Trash SHOULD be +automatically created for 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> +and removable devices) into $HOME/.Trash . 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 @@ -148,161 +141,84 @@ 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 (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 “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 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 “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 — -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 — -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 “home trash” 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> +<P>It may also choose to create <B>.Trash</B> directories in Top +directories of some mounted file systems. How these directories are +created (by the system administrator, a daemon, etc.) is determined +by the implementation.</P> +<P>Such .Trash directories are <I>not</I> +in themselves trash storage directories; this would break multi-user +support. Instead, an $topdir/.Trash directory can contain any number +of subdirectories, named for users that perform trashing operations; +i.e. <B>$topdir/.Trash/user</B> . Each of these is a trash storage +directory, containing the files trashed by this user. (See the next +section for the storage details).</P> +<P>Note that an +implementation MAY choose to support or not support trashing into +$topdir/.Trash/user. If it does support it, it SHOULD make it a +configuration option, so that the administrator can disable it for +any or all mount points for security reasons (and use $HOME/.Trash or +no trashing at all).</P> +<P>However, if a +.Trash directory does exist in any top directory, an implementation +MUST be able to list and undelete files that are in the current +user's subdirectory within it.</P> +<P>The use of +$topdir/$Trash can lead to some peculiar issues. These are discussed +in the “Implementation notes” section, at the end of +this document.</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> +directory (including $HOME/.Trash). 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> +<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="sdfootnote4anc" HREF="#sdfootnote4sym"><SUP>4</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> +overwrite a previous copy. </I>The access rights, access time and +modification time 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>. +this is never to be taken for granted<A CLASS="sdfootnoteanc" NAME="sdfootnote5anc" HREF="#sdfootnote5sym"><SUP>5</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]. +recover the original filename </B>(except in an emergency case when +an info file has been lost; this case must be clearly marked to the +user as an emergency). </P> -<P>It also must have two lines that are -key/value pairs as described in the Desktop Entry Specification:</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. The contents of this file +are:</P> +<PRE><I>original_location</I>\n +<I>trashing_time</I>\n</PRE><P> +Where:</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 (i.e., 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 only support - absolute pathnames in the “home trash” directory, not in - the directories under $topdir. + <LI><P><I>original_location</I> is 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 (i.e., from $HOME for + $HOME/.Trash); it MUST not contain “..”, and for files + not “under” that directory, absolute pathnames must be + used. </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> + <LI><P><I>trashing_time</I> is the date and time when the + file/directory was trashed. It should be a UTC (GMT) date/time in + <A HREF="http://www.cl.cam.ac.uk/~mgk25/iso-time.html">ISO 8601</A> + format: . + </P> +</UL> +<PRE STYLE="margin-bottom: 0.5cm"><I>YYYY</I>-<I>MM</I>-<I>DD</I>T<I>hh</I>:<I>mm</I>:<I>ss</I>Z</PRE> +<UL> + <LI><P>\n is the newline character.</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 @@ -310,54 +226,13 @@ 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 “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 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> +<P>[This section will contain notes on implementing all the basic +operations: trashing a file/directory, listing trash contents, +undeleting a file/directory, and emptying the trash. In particular, +it will describe the peculiarities of implementing the +$topdir/.Trash/user solution. I plan to write this section later, to +include the feedback in the FreeDesktop.org mailing list]</P> <H2>Administrativia</H2> <H3>Status of this document</H3> <P>This document is, at this moment, only a draft. It will hopefully @@ -366,49 +241,22 @@ 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>License</H3> +<P>Use 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>Redistribution and 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><A HREF="http://www.ramendik.ru/docs/trashspec.0.1.html">http://www.ramendik.ru/docs/trashspec.0.1.html</A> +is the permanent location of this version. </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><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 @@ -429,29 +277,14 @@ as implemented in KDE 3.4</P> 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/”, + <P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote4sym" HREF="#sdfootnote4anc">4</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 +<DIV ID="sdfootnote5"> + <P CLASS="sdfootnote" STYLE="margin-bottom: 0.5cm"><A CLASS="sdfootnotesym" NAME="sdfootnote5sym" HREF="#sdfootnote5anc">5</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> +</HTML>
\ No newline at end of file |