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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I suggest we clarify the meaning of file-remote-p to explain that it
>> returns info that relates to the time and reliability of the access to
>> this file.  And we introduce a new one `unhandled-file-name' which
>> returns either "an equivalent name that can passed to subprocesses"
>> (e.g. for the "/:/" file-name-handler, it just strips the leading "/:"
>> and similarly for the "file://" one) or nil if the file cannot be
>> directly accessed by a subprocess (either because it's only accessible
>> via ssh/ftp/tar/younameit it by a file-name-handler).

> At least for remote files I've introduced it silently ...
> (file-remote-p "/sudo::/etc" 'localname) returns "/etc". But you are
> right, `unhandled-file-name' would be more general but just for Tramp.

> But we shall come back to the original request of Drew: he wants to
> know whether a given file is "remote", independant of the syntax.
> Such information cannot be provided by 'file-remote-p', because that
> function has an important promise: "`file-remote-p' will never open
> a connection on its own." (from the doc-string).

That's indeed a good guaranteed, and I don't see it as an obstacle.
After all, if you'd need to contact a remote host to find out, then the
object can't be local.

> It also doesn't touch a local file; it works completely over the file
> name syntax. This promise is important because of performance.

It's not promised explicitly, tho I'm not sure what you mean by "touch".
In any case, looking at the file's contents can't be of much use.

> Rough idea: maybe one could use the device number, returned as last
> attribute of `file-attributes', for a check whether a file has been
> "mounted". I haven't seen code evaluating the device number.  And I
> don't know whether it is set to a useful value on W32, for example.

I don't think you can get any reliable useful info from the
device number.

Anyway, any objection to my proposal to clarify file-remote-p's intended
semantics, and to add unhandled-file-name (tho maybe it should be
called file-local-name, to make it closer to file-local-copy which is
kind of its complement)?


        Stefan