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

[Drew Adams]

> >> >> I just have noticed several different concerns that tend to be
> >> >> conflated:
> >> >> - reliability and performance.
> >> >> - ability to access the file via syscalls.
> >> >> - whether relative file names can be used from one file 
> >> >>   name to another.
> >> >> - whether a file's contents is directly accessible via syscalls.
> >> 
> >> > I think Drew had yet another concern, which is uncovered 
> >> > by the above.
> >> 
> >> Which one?
> 
> > The case with remote volumes mounted via the OS facilities such as
> > NFS.  They are almost identical in reliability and performance to
> > local volumes, and cannot be distinguished using file-remote-p, but
> > Drew insisted on being able to distinguish them anyway.
> 
> Not sure if it's a different case.  IIUC he's worried about the
> different reliability and/or performance of those volumes, but
> admittedly, that wasn't stated clearly,

Huh? I stated clearly and explicitly several times that my only concern was
performance.

I want a test that is quick and tells whether a file name names a file whose
access is likely to be slow, compared to a file on a local hard disk (normal
disk, no USB stick or CD etc.).

There are apparently three levels in terms of performance, from fastest to
slowest: (1) local, (2) mapped network drive, (3) truly remote (e.g. ftp/tramp
access). According to Eli's test figures, #2 was three times slower than #1, and
#3 was "two orders of magnitude" slower than #1. I won't argue the numbers -
suffice it to say that we agree that there are three levels.

`file-remote-p' currently distinguishes #1 and #2 from #3. That's reasonable,
since #3 is so much slower, per Eli's figures.

Nevertheless, I want to also be able to distinguish #1 from #2 and #3. For some
applications, a file on a mapped network drive is, like a truly remote file, too
slow, and I want to avoid accessing it. Whether the same predicate works for
both types of distinction or multiple predicates are provided, I don't care.
Whether it is `file-remote-p' or some other predicate that does what I want, I
don't care.

`file-remote-p' is also slower than it could be, at least for some file names.
For file names that `ffap-file-remote-p' determines are remote, calling it is
faster - Michael found it to be about 70 times faster than `file-remote-p'. I
suggested incorporating the ffap test into `file-remote-p'.

In any case, my only concern is performance, in two senses: (a) The main
concern, and the aim, is to avoid the cost of slow file access. (b) A secondary
concern is to make that check itself fast.