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

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

> Also, IIUC, `file-remote-p' isn't only boolean; the non-nil return value
> means something. I don't know what should be returned for a file on a mapped
> network drive.

I'm not thrilled about the non-boolean return value of file-remote-p.
Its semantics seem to be custom-tailored for Tramp and doesn't make so
much sense in general :-(

> And should we perhaps have a function that distinguishes remote files that
> are not on a mapped drive from those that are? Is there any need to
> distinguish these? (We currently do distinguish them, in that
> `file-remote-p' returns non-nil for the former and nil for the latter.)

It all depends what you want to know.  In doc-view, we recently tried to
use file-remote-p in order to figure out whether we could pass the file
name to a local process, only to discover that it wasn't the right
predicate to use.  I replaced it later on with
(let ((file-name-handlers-alist nil)) (file-readable-p <FILE>)).
I think file-remote-p should really give a kind of performance and
reliability info: is the file available from local (i.e. fast and
reliable) storage, or is it only available via a network access which
may be slow and may fail.
Now whether access via NFS should be considered as remote or not is not
clear: it's ofen used for home directories, and treating all the user's
file as "remote" is probably not a great idea.


        Stefan