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

[Michael Albinus]

Stefan Monnier <address@hidden> writes:

>> file-remote-p returns information about the *file name*, and not
>> necessarily about the file: "Can the file name be used literally on the
>> local host?" I believe this meaning shall be kept, for example, it is
>> needed to determine whether a file name must be trimmed when used as
>> argument of process-file and alike.
>
>> The new function you are looking for is file-mounted-p or so.
>
> I believe you're wrong and I'm right ;-)

For sure. At least it has been the case almost ever when we did discuss.

> What you consider as the meaning of `file-remote-p' is pretty close to
> the info returned by (let ((file-name-handlers-alist nil)) (not
> (file-readable-p <FILE>))), whereas what you want to call
> `file-mounted-p' is much closer to what `file-remote-p' currently does.
>
> E.g. (file-remote-p "/:/") will return nil, even though passing "/:/" as
> an argument to a subprocess will likely fail to do what was intended.
>
> After all, whether the filename can be passed to a subprocess has
> nothing to do with whether or not it's "remote".

Hmm. I haven't said that the result of `file-remote-p' is the only check
how to pass a file name as argument to a subprocess. But when
`file-remote-p' returns non-nil, it means that you can't take the
related file literally as part of ARGS in 'process-file' and friends.

> 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). It also doesn't touch a local file;
it works completely over the file name syntax. This promise is important
because of performance.

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.

Just for the records, ange-ftp sets it to -1, and Tramp returns (-1 x)
with x being a unique number for different remote connections.

>         Stefan

Best regards, Michael.