Trash It! 7.0.1
Initial version written by Mikhail Ramendik <mr@ramendik.ru>
Trusted Mac download Trash It! Virus-free and 100% clean download. Get Trash It! Alternative downloads. The.gov means it's official. Federal government websites often end in.gov or.mil. Before sharing sensitive information, make sure you're on a federal government site.
Content by David Faure <faure@kde.org>,Alexander Larsson <alexl@redhat.com>,Ryan Lortie <desrt@desrt.ca>and others on the FreeDesktop.org mailing list
Version 1.0
Abstract
The purpose of this Specification is to provide a common way inwhich 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 samedevices and use the same Trash storage. For example, if oneimplementation sends a file into the Trash can, another will be ableto list it, undelete it, or clear it from the Trash.
Jan 24, 2019 #comic #comictv I Was Trash Chapter 1+2 Description: He was looked down on, forced to break off his engagement, he was murdered, maybe this is the life that trash should have But he was taken. Hi i´m in 7.0.1 with reiNX right now, i´ve been out of the scene for almost 3 months so is better for me to upgrade to 8.1 or not? Dec 26, 2017 Trash It! Is an AppleScript-based application that force-empties your Trash and/or removes stubborn items. Especially useful if you have files or folders in the Trash with permissions set incorrectly, locked Trash items, want to securely delete a stuck item, or trash items from other partitions.
- Oct 10, 2019 The.gov means it's official. Federal government websites often end in.gov or.mil. Before sharing sensitive information, make sure you're on a federal government site.
- Jul 26, 2017 We all know Samsung is working on its brand new Android 7.1.1 Nougat firmware update. The current Android 7.0 Nougat is called Samsung Experience 8.1, whereas, the earlier 6.0.1 Marshmallow is called TouchWiz.
Introduction
An ability to recover accidentally deleted files has become the defacto standard for today's desktop user experience.
Users do not expect that anything they delete is permanently gone.Instead, they are used to a “Trash can” metaphor. Adeleted document ends up in a “Trash can”, and staysthere at least for some time — until the can is manually orautomatically cleaned.
This system has its own problems. Notably, cleaning disk spacebecomes a two-step operation — delete files and empty trash;this can lead to confusion for inexperienced users (“what'staking up my space?!”). Also, it is not easy to adapt thesystem to a multiuser environment. Besides, there is a potential forabuse by uneducated users — anecdotal evidence says theysometimes store important documents in the Trash can, and lose themwhen it gets cleaned!
However, the benefits of this system are so great, and the userexpectation for it so high, that it definitely should be implementedon a free desktop system. And in fact, several implementationsexisted before this specification — some as command line utilities, some aspreloaded libraries, and some as parts of major desktop environments.For example, both Gnome and KDE had their own trash mechanisms.
This Specification is to provide a common way in which all Trashcan implementations must store trashed files. By complying withthis Specification, various Trash implementations will be able towork with the same devices and use the same Trash storage.
Serial box 02.2020. This ability is important, at least, for shared network resources,removable devices, and in cases when different implementations areused on the same machine at different moments (for example, some users preferGnome, others prefer KDE, and yet others are command-line fans).
Scope and limitations
This Specification only describes the Trash storage. It does notlimit the ways in which the actual implementations should operate, aslong as they use the same Trash storage. Command line utilities,desktop-integrated solutions and preloaded libraries can work withthis specification. 1
This Specification is geared towards the Unix file system treeapproach. However, with slight modifications, it can easily be usedwith another kind of file system tree (for example, with driveletters).
A multi-user environment, where users have specific numericidentifiers, is essential for this Specification.
File systems and logon systems can becase-sensitive or non-case-sensitive; therefore, systems shouldgenerally not allow user names that differ only in case.
Definitions
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.
Trashing — a “delete” operation in which filesare transferred into the Trash can.
Erasing — an operation in which files (possibly already inthe Trash can) are removed (unlinked) from the file system. An erasedfile is generally considered to be non-recoverable; the space used bythis file is freed. [A “shredding” operation, physicallyoverwriting the data, may or may not accompany an erasing operation;the question of shredding is beyond the scope of this document].
Original location — the name and location that a file(currently in the trash) had prior to getting trashed.
Original filename — the name that a file (currently in thetrash) had prior to getting trashed.
Top directory , $topdir — the directory where a file systemis mounted. “/” is the top directory for the root filesystem, 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”.
User identifier , $uid — the numeric user identifier for auser. $uid is used here as “the numeric user identifier of theuser who is currently logged on”.
Trash directory — a directory where trashed files, as wellas the information on their original name/location and time oftrashing, are stored. There may be several trash directories on onesystem; this Specification defines their location and contents. Inthis text, the designation “$trash” is used for “anytrash directory”.
“Home trash” directory — a user's main trashdirectory. Its name and location is defined in this document.
The key words 'MUST', 'MUST NOT', 'REQUIRED','SHALL', 'SHALL NOT', 'SHOULD', 'SHOULDNOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL'in this document are to be interpreted as described in RFC2119.
Trash directories
A system can have one or more trash directories. The contents ofany trash directory are to be compliant with the same standard,described below.
For every user2a “home trash” directory MUST be available.Its name and location are $XDG_DATA_HOME/Trash 3; $XDG_DATA_HOME isthe base directory for user-specific data, as defined in the DesktopBase Directory Specification .
The “home trash” SHOULD function as the user's maintrash directory. Files that the user trashes from the same filesystem (device/partition) SHOULD be stored here (see the next sectionfor the storage details). A “home trash” directory SHOULDbe automatically created for any new user. If this directory isneeded for a trashing operation but does not exist, theimplementation SHOULD automatically create it, without any warningsor delays.
The implementation MAY also support trashing files from the restof 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 filelocations, the user can not fill up any space except the homedirectory, and as other users generally do not have access to it, nosecurity issues arise.
However, this solution leads to costly file copying (betweenpartitions, over the network, from a removable device, etc.) A delayinstead of a quick “delete” operation can be unpleasantto users.
An implementation MAY choose not to support trashing in some ofthese cases (notably on network resources and removable devices).This is what some well known operating systems do.
It MAY also choose to provide trashing in the “topdirectories” of some or all mounted resources. This trashing isdone in two ways, described below as (1) and (2).
(1) An administrator can create an $topdir/.Trash directory. Thepermissions on this directories should permit all users who can trashfiles at all to write in it.; and the “sticky bit” in thepermissions must be set, if the file system supports it.
When trashing a file from a non-home partition/device4, an implementation (if it supports trashing in top directories) MUSTcheck for the presence of $topdir/.Trash.
When preparing a list of all trashed files (for example, to show to theuser), an implementation also MUST check for .Trash in all topdirectories that are known to it.
If this directory is present, the implementation MUST, by default,check for the “sticky bit”. (It MAY provide a way for theadministrator, and only the administrator, to disable thischecking for a particular top directory, in order to support filesystems that do not have the “sticky bit”).
The implementation also MUST check thatthis directory is not a symbolic link.
If any of these checks fail, theimplementation MUST NOT use this directory for either trashing orundeleting files, even if an appropriate $uid directory (see below)already exists in it. Besides, the implementation SHOULD report thefailed check to the administrator, and MAY also report it to theuser.
The following paragraph applies ONLY tothe case when the implementation supports trashing in the topdirectory, and a $topdir/.Trash exists and has passed the checks:
If the directory exists and passes thechecks, a subdirectory of the $topdir/.Trash directory is to be usedas the user's trash directory for this partition/device. The name ofthis subdirectory is the numeric identifier of the current user($topdir/.Trash/$uid). When trashing a file, if this directory doesnot exist for the current user, the implementation MUST immediatelycreate it, without any warnings or delays for the user.
(2) If an $topdir/.Trash directory isabsent, an $topdir/.Trash-$uid directory is to be used as the user'strash directory for this device/partition. $uid is the user's numericidentifier.
The following paragraph applies ONLY tothe case when the implementation supports trashing in the topdirectory, and a $topdir/.Trash does not exist or has not passed thechecks:
When trashing a file,if an $topdir/.Trash-$uid directory does not exist, theimplementation MUST immediately create it, without any warnings ordelays for the user.
When trashing a file, if this directorydoes not exist for the current user, the implementation MUSTimmediately create it, without any warnings or delays for the user.
Notes. If an implementation provides trashing in topdirectories at all, it MUST support both (1) and (2).
If an implementation does NOT provide trashing in top directories, and doesprovide the user with some interface to view and/or undelete trashedfiles, it SHOULD make a “best effort” to show filestrashed in top directories (by both methods) to the user, among othertrashed files or in a clearly accessible separate way.
When trashing a file, if the method (1) fails at any point —that is, the $topdir/.Trash directory does not exist, or it fails thechecks, 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 thechecks, the fallback must be immediate, without any warnings ordelays. The implementation MAY, however, provide a way for the administratorto disable (2) completely.
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 thefile into the user's “home trash” or refuse to trash it.The choice between these options can be pre-determined, or it candepend on the particular situation (for example, “no trashing of very largefiles”). However, if an implementation refuses to trash a file after auser action that generally causes trashing, it MUST clearly warn theuser that the trashing has failed. It MUST NOT erase the file without user confirmation.
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 fromboth of them).
Contents of a trash directory
The previous section has described the location of trashdirectories. This section concerns the contents of any trashdirectory (including the “home trash” directory). Thistrash directory will be named “$trash” here.
A trash directory contains two subdirectories, named info andfiles.
The $trash/files directory contains the files anddirectories that were trashed. When a file or directory is trashed,it MUST be moved into this directory5. The names of files in this directory are to be determined by theimplementation; the only limitation is that they must be uniquewithin the directory. Even if a file with the same name andlocation gets trashed many times, each subsequent trashing must notoverwrite a previous copy. The access rights, access time,modification time and extended attributes (if any) for afile/directory in $trash/files SHOULD be the same as thefile/directory had before getting trashed.
IMPORTANT NOTE. While an implementation may choose to basefilenames in the $trash/files directory on the original filenames,this is never to be taken for granted6.A filename in the $trash/files directory MUST NEVER be used torecover the original filename; use the info file (see below) forthat. (If an info file corresponding to a file/directory in$trash/files is not available, this is an emergency case, and MUST beclearly presented as such to the user or to the systemadministrator).
The $trash/info directory contains an “informationfile” for every file and directory in $trash/files. This fileMUST have exactly the same name as the file or directory in$trash/files, plus the extension “.trashinfo”7.
The format of this file is similar to the format of a desktopentry file, as described in the DesktopEntry Specification . Its first line must be [Trash Info].
It also must have two lines that arekey/value pairs as described in the Desktop Entry Specification:
Adobe audition cc 2019 torrent. This powerful audio workstation is designed to accelerate video production workflows and audio finishing — and deliver a polished mix with pristine sound.Adobe Audition gives you all the features you need for professional recording and production of audio.
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.
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 RFC2396, section 2).
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 RFC 3339). The time zone should be the user's (or filesystem's) local time. The value type for this key is “string”.
Example:
The implementation MUST ignore any other lines in this file, exceptthe 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.8
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 movedto $trash/files with its entire contents. The names of the files anddirectories within the directory MUST NOT be altered; theimplementation also SHOULD preserve the access and modification timefor them.
When trashing a file or directory, the implementation MUST createthe corresponding file in $trash/info first. Moreover, it MUST try to do this in an atomicfashion, so that if two processes try to trash files with the samefilename this will result in two different trash files. On Unix-linesystems this is done by generating a filename, and then opening withO_EXCL. If that succeeds the creation was atomic (at least on thesame machine), if it fails you need to pick another filename.
Directory size cache
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$trash/directorysizes file, which is a cache of the sizes of the directoriesthat were trashed into this trash directory.Individual trashed files are not present in this cache, since their size can be determinedwith a call to stat().
Each entry contains the name and size of the trashed directory, as well as the modificationtime of the corresponding trashinfo file (IMPORTANT: not the modification time of the directory itself)9.
The size is calculated as the disk space used by the directory and itscontents, that is, the size of the blocks, in bytes (in the same way as the `du -B1` command calculates).
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.
The “directorysizes” file has a simple text-based format, where each line is:
Example:
The last entry on each line is the name of the trashed directory, stored as thesequence of bytes produced by the file system, with characters escapedas in URLs (as defined by RFC 2396, 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 filesis perfectly valid, and even if an implementation does not use such encoding. it MUST be able to read names encoded with it.
The character '/' is not allowed in the directory name (even as %2F), since all thesedirectories must be direct children of the 'files' directory. Absolute paths are not allowed for the same reason.
To update the directorysizes file, implementations MUST use a temporary file followed by an atomic rename() operation, in orderto avoid corruption due to two implementations writing to the file at the same time. The factthat the changes from one of the writers could get lost isn't an issue, as the cache can be updated againlater on to add that entry.
Non-normative: suggested algorithm for calculating the size of a trash directory
Implementation notes
The names of the files/directories in $trash/info SHOULD besomehow related to original file names. This can help manual recoveryin emergency cases (for example, if the corresponding info file islost).
When trashing a file or directory, the implementation SHOULD checkwhether the user has the necessary permissions to delete it, beforestarting the trashing operation itself.
Trash It 7.0.1 App
When copying, rather than moving, a file into the trash (whentrashing to the “home trash” from a different partition),exact preservation of permissions might be impossible. Notably, afile/directory that was owned by another user will now be owned bythis user (changing owners is usually only available to root). ThisSHOULD NOT cause the trashing operation to fail.
In this same situation, setting the permissions should be doneafter writing the copied file, as they might make itunwriteable.
A trashing operation might be refused because of insufficientpermissions, even when the user does have the right to delete a fileor directory. This may happen when the user has the right to delete afile/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 theuser, offering options to delete the file/directory or leave italone. As noted earlier, when the user reasonably expects a file to betrashed, the implementation MUST NOT delete it without warning the user.
Automatic trash cleaning may, and probably eventually should, beimplemented. But the implementation should be somehow known to theuser.
If a directory was trashed in its entirety, it is easiest toundelete it or remove it from the trash only in its entirety as well,not as separate files. The user might not have the permissions todelete some files in it even while he does have the permission todelete the directory!
Important note on scope. This specification currently doesNOT define trashing on remote machines where multiuser permissionsare implemented but the numeric user ID is not supported, like FTPsites and CIFS shares. In systems implementing this specification,trashing of files from such machines is to be done only to the user'shome trash directory (if at all). A future version may address thislimitation.
Administrativia
Copyright and License
Copyright (C) 2004-2014 Mikhail Ramendik , mr@ramendik.ru.
The originators of the ideas that are described here did notobject to this copyright. The author is ready to transfer thecopyright to a standards body that would be committed to keeping thisspecification, or any successor to it, an open standard.
The license: Use and distribute as you wish. If you make amodified version and redistribute it, (a) keep the name of the authorand contributors somewhere, and (b) indicate that this is a modifiedversion.
Implementation under any license at all is explicitly allowed.
Trash It 7.0.1 Software
Location
http://standards.freedesktop.org/trash-spec/trashspec-latest.html.
Version history
0.1 “First try”, August 30, 2004. Initial draft.“Implementation notes” not written as yet.
0.2 August 30, 2004. Updated with feedback by Alexander Larsson<alexl@redhat.com> and byDave Cridland <dave@cridland.net>
0.3 September 8, 2004. Changed the name and location of the “hometrash” directory, and introduced the generic term “hometrash”. Changed the trash info file format to a .desktop-likeone. Added directions on creation of info files and copying oftrashed files. Changed user names to user ids. Added implementationnotes. Added a copyright notice.
0.4 September 9, 2004. Changed [Trash entry] to [Trash info] andfixed some typo's
0.5 September 9, 2004. Changed [Trash info] to [Trash Info]
0.6 October 8, 2004. Corrections by Alexander Larsson<alexl@redhat.com> . Alsoadded “note on scope”. Cleaned up HTML. Added a link to this document on the freedesktop.org standards page
0.7 April 12, 2005. Added URL-style encoding for the name of the deleted file,as implemented in KDE 3.4
0.8 March 14, 2012. Update David Faure's email address, fix permanent URL for this spec.
1.0 January 2, 2014. Add directorysizes cache; style review.
1However, 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.
2To 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.
Trash It 7.0.1 Free
4To be more precise, from a partition/device different from the one on which $XDG_DATA_HOME resides.
Trash It 7.0.1 Tool
5“$trash/files/”, not into “$trash/” as in many existing implementations!
6At least because another implementation might trash files into the same trash directory
Trash It 7.0.1 Pro
7For example, if the file in $trash/files is named foo.bar , the corresponding file in $trash/info MUST be named foo.bar.trashinfo
9Rationale: 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.