GNU bug report logs -
#58721
28.2; dired with delete-by-moving-to-trash can't trash directory twice
Previous Next
Reported by: Gustavo Barros <gusbrs.2016 <at> gmail.com>
Date: Sat, 22 Oct 2022 18:24:01 UTC
Severity: normal
Found in version 28.2
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #59 received at 58721 <at> debbugs.gnu.org (full text, mbox):
On Fri, 28 Oct 2022 at 13:06, Gustavo Barros <gusbrs.2016 <at> gmail.com> wrote:
> > I get the same result. But I think this is expected, as the
> > `rename-file' docstring says:
> >
> > For NEWNAME to be recognized as a directory name, it should
> > end in a slash.
> >
> > So this function seems to be working as documented.
> That is, no end slash appended to the directory at
> `move-file-to-trash'. So, it appears we have a good suspect. Why it
> works when the filesystem is the same still beats me.
Uhm, it is still not this. The previous sentence in the docstring you
(Stefan) mentioned is:
If NEWNAME is a directory name, rename FILE to a like-named file under
NEWNAME. For NEWNAME to be recognized as a directory name, it should
end in a slash.
And, indeed, if we do:
(rename-file "/path/to/orig/barbaz" "/path/to/dest/barbaz-foobar/" t)
the operation succeeds, but the result is:
/path/to/dest/barbaz-foobar/barbaz/zero.file
And that's not what we want, or not what `move-file-to-trash' is
trying to do. And that is precisely why it is passing the
`ok-if-already-exists' as `t' there in the first place.
In other words, as far as I can see, the sentence:
For NEWNAME to be recognized as a directory name, it should
end in a slash.
should not imply that if `ok-if-already-exists' is `t' `rename-file'
should fail to overwrite, whether the `newname' is a directory or not.
This bug report was last modified 2 years and 182 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.