GNU bug report logs - #49711
27.2; Deleting a directory called ~ deletes home directory

Previous Next

Full log

Message #27 received at 49711 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: abdo.haji.ali <at> gmail.com, 49711 <at> debbugs.gnu.org
Subject: Re: bug#49711: 27.2; Deleting a directory called ~ deletes home
 directory
Date: Sat, 24 Jul 2021 15:40:30 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: abdo.haji.ali <at> gmail.com,  49711 <at> debbugs.gnu.org
> Date: Sat, 24 Jul 2021 14:27:21 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Hmm... you replaced expand-file-name with directory-append, but what
> > if there's a real "~" in the arguments, or some ".." etc. stuff?  That
> > would now wind up in the trash info, no?
> 
> Sorry, I don't follow you here -- if we're trashing a file called
> "/tmp/~", then the "~" file ends up in the trash now, as expected.
> 
> Do you mean "~/foo"?  That works the same as before.

Does it?  And what gets recorded in the trash info -- "~/foo" or its
expansion?  If the latter, where does that expansion happen?

And what about relative file names, as in "foo/bar" -- what gets
recorded in trash info then?

> (Moving "/tmp/.." to trash fails the same way as before.)

What about /foo/bar/../baz/../quux/something -- what gets recorded in
trash info?

Btw, the implementation of directory-append is sub-optimal: it
allocates space for the combined string twice.  It is better to create
an uninit Lisp string first, and then fill its data with the right
contents.

Previous Next

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