GNU bug report logs - #1440
23.0.60; delete-by-moving-to-trash loses data

Previous Next

Package: emacs;

Reported by: Tassilo Horn <tassilo <at> member.fsf.org>

Date: Thu, 27 Nov 2008 15:50:04 UTC

Severity: grave

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


Message #26 received at 1440-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Tassilo Horn <tassilo <at> member.fsf.org>,
        1440-done <at> debbugs.gnu.org
Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems
Date: Sun, 28 Dec 2008 20:34:37 +0000
Chong Yidong wrote:
>>> I'd propose to let-unbind backup-directory-alist when making backups
>>> for deleted files.
>> That seems sensible/necessary.
> 
> Done.
>

[Note that the "hierarchy flattening" issue in 1440 isn't addressed by 
that, though maybe should not be considered grave/release-blocking]

BTW, I now think there are further trash (or underlying file/directory 
operations) problems in some cross-device dir-tree trashing contexts 
(possibly for both the fallback trash and fd.o patch), will try and make 
a reproducible case and file a new bug I guess, holiday season 
commitments slowing me a bit, sorry.

> David's patch in bug#973, which implements the Freedesktop trash can,
> looks good... but I think we should wait till after the release to
> include it.

Wouldn't really want to cause release delay because of it (and it would 
need testing, and might have knock-on effects e.g. needing to (re)write 
macosx trashcan support - I don't even have a macosx box at present, I 
for one can't do that very easily).

Obvious concern would be if trashcan support is being newly introduced, 
doing fd.o trashing from the start on platforms that use fd.o trash 
would avoid confusion* and bug reports.

* Particularly inventive end-users redirecting the fallback trash at the 
fd.o trash path rather than at the fallback trash's default path will 
make a bit of a mess in their fd.o trash (fd.o apps will wonder where 
the undelete metadata is), might want to keep an eye out for that - not 
really a bug in the emacs fallback trash if such metadata isn't recorded 
by it if it's not an implementation of fd.o trashing in the first place...


































This bug report was last modified 15 years and 151 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.