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

Previous Next

Full log

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

From: David De La Harpe Golden <david <at> harpegolden.net>
To: 1440 <at> debbugs.gnu.org, Tassilo Horn <tassilo <at> member.fsf.org>
Subject: Re: bug#1440: Concerning delete-by-moving-to-trash on free systems
Date: Mon, 01 Dec 2008 20:00:21 +0000

> I'd propose to let-unbind backup-directory-alist when making backups
> for deleted files.

That seems sensible/necessary.
Though I think that maybe backup and trashing code paths should just be 
decoupled to avoid ongoing problems - i.e. have  move-file-to-trash just 
not use find-backup-file-name. What happens when someone next changes 
the backup-file subsystem, or a user locally patches it?  fallback 
trashing silently breaks, of course, surprise! There's also the minor 
point that find-file-name handlers can't distinguish a fallback trash 
operation from a backup operation at present and might conceivably do 
the wrong thing.

And of course, all this is about fixing the fallback trashcan, which as 
already noted doesn't correspond to the free desktop trashcan. It 
probably isn't a proper  implementation of the macosx trashcan really 
either (should probably really be  using the relevant system trash api 
on that platform , which appears to be (though I'm not a  macosx 
programmer, just cursory google search) NSWorkspaceRecycleOperation  or 
maybe FSMoveObjectToTrashSync)

Previous Next

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