GNU bug report logs - #16984
dired-do-rename susceptible to .../~/... hijack

Previous Next

Full log

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: npostavs <at> users.sourceforge.net
Cc: Eli Zaretskii <eliz <at> gnu.org>, 16984 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#16984: dired-do-rename susceptible to .../~/... hijack
Date: Sat, 29 Oct 2016 18:22:01 +0200

npostavs <at> users.sourceforge.net writes:

>> Prefixing with "/:" would also deactivate all file name handlers. The
>> file name "/ssh:user <at> host:/path/~/file" would be handled literally,
>> which is wrong.
>
> Ah, good point.  How about checking (find-file-name-handler filename
> 'substitute-in-file-name):
>  
> +           (not (let ((handler (find-file-name-handler
> +                                filename 'substitute-in-file-name)))
> +                  (and handler
> +                       (funcall handler 'substitute-in-file-name filename)))))

I would rather use (not (file-remote-p file-name))

This fixes the problem for local file names, but not for remote
ones. "/ssh:user <at> host:/path/~/file" would still be expanded to something
like "/ssh:user <at> host:/home/user/file". Well, better than nothing.

What do people think to use the "/:" prefix also for the local part of
remote file names? Then one could use "/ssh:user <at> host:/:/path/~/file",
making substitute-in-file-name a noop.

Best regards, Michael.

Previous Next

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