RE: testing for a remote file to include file on a Windows mapped drive

["Drew Adams" <drew.adams@oracle.com>]

> > As I said, I want to know if a file name is likely to represent a remote
> > file (in the Emacs sense you cited) or a file on a mapped network drive.
> >
> > The reason is to avoid the time needed to access the remote machine.
>
> What kind of access is that, and how much time does it take, that you
> want to avoid it?  Do you have any numbers, even approximate ones,
> that compare access to local vs remote files on mounted volumes?

No.

> > That's the same reason that most of the above were defined, but they
> > don't handle the network-drive case.
>
> Accessing a remote file via the normal filesystem API (which is what
> happens with remote drives and NFS-mounted volumes) is several orders
> of magnitude faster than Tramp or ange-ftp.  So I find it hard to
> believe that the same primitive would fulfill both of these needs.

I didn't say anything about using "the same primitive". I explicitly said
that a different function might be provided. I'm indifferent as to whether
`file-remote-p' should be tweaked to take this into account or a new
function should be added. I and others have pointed out that `file-remote-p'
is already ambiguous in terms of its aim or use. It would be good to clarify
things and sort this out.

In the case of a file on a mapped network drive, it takes just as long, for
my setup at least, in terms of perception. I have no numbers, and I don't
need any. It is too long for me (and for people who reported the problem to
me). Today, AFAIK, there is no test for this, and `file-remote-p' returns
nil for such a file. Code that uses `file-remote-p' (or any of the regexps I
cited) does not avoid the performance hit from trying to access a file on a
network drive.

Perhaps the performance depends also on the particular remote machine and
its connectivity, VPN, firewall, etc. I don't know, and I don't care. For
me, it does no good to argue that accessing a mapped network drive is
"several orders of magnitude" faster than using Tramp or FTP. It is not
*noticeably* faster in my case, and, more importantly, it is much, much
slower for me than accessing a local file. No numbers; only perception. It
might be orders of magnitude faster, but it is too slow for me.

Trust me - If a file name is likely to represent a file that is on a network
drive, then I usually want to treat it as the name of a remote file in terms
of avoiding unnecessary access. That's all.