GNU bug report logs - #5436
23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan

Previous Next

Full log

View this message in rfc822 format

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>, 5436 <at> debbugs.gnu.org
Subject: bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan
Date: Wed, 27 Jan 2010 00:06:11 +0000

Chong Yidong wrote:

> I understand what you are saying.  How about conditioning the
> delete-directory change on delete-by-moving-to-trash?

Unless I'm misunderstanding you (or did you mean the rename-file change?*):

delete-directory with the delete-directory part of the patch already 
becomes conditionalised on delete-by-moving-to-trash. See the patch
introducing "(if delete-by-moving-to-trash ...[a]... ...[b]...)"

[a] delete-by-moving-to-trash non-nil, delete-directory called with a 
directory arg and arg recursive non-nil:

a single call to move-file-to-trash is made in delete-directory, so that 
move-file-to-trash can handle the directory tree as a unit**.

[b] delete-by-moving-to-trash nil, delete-directory called with a
directory arg and arg recursive non-nil:

the original self-recursive code path in delete-directory is used - it's 
really deleting, so delete-directory just walks the tree and deletes 
everything, calling itself recursively - there's no need for renames and 
copies in this case, so what happens cross-device doesn't matter***

* If so, I think that would be a tad confusing, anyway. Probably 
possible, but would be getting a bit difficult to follow IMO (remember 
even an unpatched rename-file already wraps delete-by-moving-to-trash to 
nil around a call to delete-file.)

** With the other part of the patch (the more controversial change to 
rename-file), when move-file-to-trash then calls the extended 
rename-file to actually do the move,  the extended rename-file may call 
delete-directory again, but with with delete-by-moving-to-trash 
dynamically bound to nil around it to really delete after 
copy-directory, meaning path [a] does ultimately internally sometimes 
use path [b]. That is highly similar to the way the unpatched 
rename-file calls delete-file in the xdev with delete-by-moving-to-trash 
bound to nil around it to really delete files after copy-file, emulating 
a rename cross-device.


*** come to think of it, except for mountpoints that exist below
the directory being deleted ...wonder what happens then...

Previous Next

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