bug#5478: 23.1.91; Cannot use dired with cons DIRNAME arg if include remote files

bug#5478: 23.1.91; Cannot use dired with cons DIRNAME arg if include remote files

[Drew Adams]

emacs -Q

I load these two files:
http://www.emacswiki.org/emacs/cygwin-mount.el
http://www.emacswiki.org/emacs/setup-cygwin.el

I use ftp as `tramp-default-method' (I gave up trying to use Tramp with
ssh on Windows).

But probably none of that is important. What follows is what matters.


M-: (dired '("foo" A B))

where A is an (absolute) remote file name and B is an (absolute) local
file name.  For example, A could be
"/zizi.bar.toto.com:/some/path/titi.el", and B could be
"c:/another/path/tata.el".

The Dired buffer that results shows file B normally:
it is correctly listed using its absolute file name.
The buffer is correctly named "foo".

The listing shows file A incorrectly, however. It shows A as a relative
file name, instead of showing it as an absolute, remote file name. IOW,
the remote directory information is lost.

And hitting RET on A's line in Dired raises this error: "File no longer
exists; type `g' to update dired buffer".  That message is
inappropriate, obviously.  And `g' does not help.

This is really too bad.  It is _very_ convenient to use Dired with an
explicit list of files, e.g. files from different directories.  It would
be especially convenient to be able to mix local and remote files this
way.

And according to the Dired doc, this should work.  It almost does.  In
fact, the file line for the remote file is otherwise correct - e.g. the
date/time, permissions, etc.  The only problem seems to be that the
directory itself is missing: the file name is displayed as a relative
name.  If it were displayed as absolute, I'm guessing it would work 100%.

In GNU Emacs 23.1.91.1 (i386-mingw-nt5.1.2600)
 of 2010-01-02 on PRETEST
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

bug#5478: 23.1.91; Cannot use dired with cons DIRNAME arg if include remote files

[Drew Adams]

Here is some info about the cause of this bug. It has to do with the very
different way that local and remote file and directory names are handled by
`insert-directory'. Remote names are not handled correctly.

Local file and dir names are inserted into Dired verbatim: if they are absolute
names, then they remain such.

Remote names are instead relativized (they should not be). And in the case of a
remote directory name, instead of the directory name itself being inserted, its
constituent file names are inserted. (So there are in fact two bugs, or two
aspects to this bug.)

Here are some details:

`dired-internal-noselect' calls `dired-readin', which calls `insert-directory'
for each of the absolute file names in `dired-directory', which is the cons from
the DIR-OR-LIST arg to `dired-internal-noselect'.

The problem for a remote file name or a remote directory name as one of the
elements of the cons comes I think from this code in the definition of
`insert-directory' in ls-lisp.el:

(let ((handler (find-file-name-handler (expand-file-name file)
					   'insert-directory))
	  (orig-file file)
	  wildcard-regexp)
      (if handler
	  (funcall handler 'insert-directory file switches
		   wildcard full-directory-p)

and this code in ange-ftp.el:

(put 'insert-directory 'ange-ftp 'ange-ftp-insert-directory)

When a local directory name or an (absolute) local file name is an element of
the cons DIRNAME, `insert-directory' just inserts it verbatim as a single name
in the Dired buffer. That is the correct behavior for the cons DIRNAME case:
each file or dir in the cons should just be inserted in the Dired buffer. This
is done by calling `ls-lisp-insert-directory'.

But when a remote directory name or a remote (absolute) file name is an element
of the cons DIRNAME, the handler `ange-ftp-insert-directory' is called. For a
remote directory name element, it inserts the relative file names of the files
in that remote dir, instead of just inserting the remote dir name itself. For a
remote file-name element, it inserts the relative name instead of the absolute
file name.

IOW, for local files and dirs, `insert-directory' just inserts the names. For
remote files and dirs, it inserts relative file names. And in the case of a
remote dir, it inserts the (relative) names of the files in the dir, instead of
the dir name itself.

bug#5478: 23.1.91; Cannot use dired with cons DIRNAME arg if include remote files

[Drew Adams]

> The problem for a remote file name or a remote directory name 
> as one of the elements of the cons comes I think from this code
> in the definition of `insert-directory' in ls-lisp.el:
> 
> (let ((handler (find-file-name-handler (expand-file-name file)
> 					   'insert-directory))
...
>       (if handler
> 	  (funcall handler 'insert-directory file switches
> 		   wildcard full-directory-p)

The same code is in the definition of `insert-directory' that is found in
files.el, so this bug is probably not only for users of ls-lisp.el (e.g. Windows
users).

bug#5478: 23.1.91; Cannot use dired with cons DIRNAME arg if include remote files

[Michael Albinus]

"Drew Adams" <drew.adams@oracle.com> writes:

> The same code is in the definition of `insert-directory' that is found in
> files.el, so this bug is probably not only for users of ls-lisp.el (e.g. Windows
> users).

I could reproduce it with gnu/linux. Fixed in ange-ftp.el and
tramp.el. Some cosmetics in dired listing layout might be left, I'm not
familiar with this.

I haven't tested it for W32.

Best regards, Michael.

bug#5478: 23.1.91; Cannot use dired with cons DIRNAME arg if include remote files

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

> I could reproduce it with gnu/linux. Fixed in ange-ftp.el and
> tramp.el. Some cosmetics in dired listing layout might be left, I'm not
> familiar with this.
>
> I haven't tested it for W32.

Remote files are handled correct now, also under W32 (according to the
OP). The bug is closed therefore.

During the tests, two other bugs have been detected, bug#5516 and
bug#5551. They are not related to remote files in particular, therefore
they shall be treated independently.

Best regards, Michael.