From: David De La Harpe Golden <david@harpegolden.net>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: Tassilo Horn <tassilo@member.fsf.org>, 5436@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 [thread overview]
Message-ID: <4B5F8373.7080004@harpegolden.net> (raw)
In-Reply-To: <87ockghmy6.fsf@stupidchicken.com>
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...
next prev parent reply other threads:[~2010-01-27 0:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-21 12:50 bug#5436: 23.1.91; Deleting directories causes unusable file layout in freedesktop trashcan Tassilo Horn
2010-01-22 16:20 ` Chong Yidong
2010-01-22 22:58 ` David De La Harpe Golden
2010-01-24 4:14 ` David De La Harpe Golden
2010-01-24 9:46 ` Tassilo Horn
2010-01-24 18:24 ` Eli Zaretskii
2010-01-24 20:19 ` David De La Harpe Golden
2010-01-24 20:25 ` David De La Harpe Golden
2010-01-25 19:00 ` Chong Yidong
2010-01-25 23:33 ` David De La Harpe Golden
2010-01-26 16:04 ` Chong Yidong
2010-01-27 0:06 ` David De La Harpe Golden [this message]
2010-01-27 4:10 ` Chong Yidong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B5F8373.7080004@harpegolden.net \
--to=david@harpegolden.net \
--cc=5436@debbugs.gnu.org \
--cc=cyd@stupidchicken.com \
--cc=tassilo@member.fsf.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.