Re: testing for a remote file to include file on a Windows mappeddrive

[Stefan Monnier]

> Just that your proposal (use file-relative-name for trimming arguments
> of remote subprocesses) works only, if the remote side has a UNIX-like
> filesystem with a unique root "/". Given, that remote subprocesses are
> implemented today just for such types of remote hosts, it is a
> sufficient assumption.

It should still work on systems without a unique / root, as long as
file-remote-p returns different values for different roots.
It may work suboptimally, in that file-relative-name may return an
absolute file name, indicating that "it can't be reached" whereas it
actually can be reached, but I think this is OK for now.

>>> Just being curious: url-handlers.el misses an own implementation of
>>> `file-remote-p'; shouldn't it be there?
>> Yes, it should.  Patches welcome ;-)
> I'll do so. But it raises the question: Is "file:///toto/titi" remote? I
> would say no, but it depends how file-remote-p is used. If it is applied
> in tests like "Can I use the filename literally for local purposes",
> then (file-remote-p" file:///toto/titi") must return a non-nil value.

Welcome to this thread, which started around the discussion of what
file-remote-p should do and how that relates to
file-local-name/unhandled-file-name.  As has now been made more explicit
in the docstring, file-remote-p is intended to give an indication about
the speed and reliability of access to the file, not about whether the
filename can be passed to subprocesses.

The fact that file-remote-p is also used by file-relative-name is
probably bad and will sooner or later lead to situations where it's
unclear what file-remote-p should return.

At that point, we may want to introduce a new file name handler.


        Stefan