bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan

[David De La Harpe Golden <david@harpegolden.net>]

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...