On Fri, 15 May 2015 12:56 pm, Chris Angelico wrote: > On Fri, May 15, 2015 at 12:49 PM, Ian Kelly <ian.g.ke...@gmail.com> wrote: >> On May 14, 2015 7:55 PM, "Chris Angelico" <ros...@gmail.com> wrote: >>> (Though when >>> it comes to the bikeshedding phase, I'm sure there'll be some who say >>> "if it can't be trashed, just hard delete it", and others who say "if >>> it can't be trashed, raise an exception". And neither is truly wrong.) >> >> The answer is "raise an exception". Moving to trash and deleting are >> different operations, and one shouldn't be substituted for the other any >> more than a failed attempt to create a hard link should create a soft >> link instead. >> >> If the user wants, they can catch the exception and delete the file >> instead. Recovering from an accidental deletion would be more difficult. > > Yes, but sometimes it's at the file system's discretion - particularly > when you're working with network mounts. The application may not even > know that the file got hard deleted.
Citation needed. "Move to trash" is a move operation, not an unlink. By definition, it is reversible. Which platforms/file systems implements it as an unlink? (I think the answer is, "broken ones".) I've never heard of any file system implement a move to trash operation as a primitive, it's always implemented at the application layer (desktop management being an application for these purposes). As far as the file system is concerned, it is just a file rename, or very occasionally if the implementation is lousy, a copy followed by delete. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
