[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#5436: 23.1.91; Deleting directories causes unusable file layout in f
From: |
David De La Harpe Golden |
Subject: |
bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan |
Date: |
Wed, 27 Jan 2010 00:06:11 +0000 |
User-agent: |
Mozilla-Thunderbird 2.0.0.22 (X11/20091109) |
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...
- bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan, (continued)
- bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan, Chong Yidong, 2010/01/22
- bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan, Chong Yidong, 2010/01/25
- bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan, David De La Harpe Golden, 2010/01/25
- bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan, Chong Yidong, 2010/01/26
- bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan,
David De La Harpe Golden <=
- bug#3353: bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan, Chong Yidong, 2010/01/26