RE: testing for a remote file to include file on a Windowsmapped drive

[Drew Adams]

> This is a 3-fold slowdown for a networked volume, and accessing 11
> directories with a plethora of file I/O APIs still takes a fraction of
> a second.
> 
> By contrast, just typing "plink fencepost.gnu.org 'ls -l test'" to
> produce a listing of a directory on a drive ``half a globe away'' from
> where I physically sit takes 4 seconds, and that's even without the
> Tramp overhead that could well double or even triple that time.  So
> access to what we now call ``remote'' files is 2 orders of magnitude
> slower than accessing a local file.
> 
> Given these numbers, I fail to see how the same simple predicate can
> satisfy the need for detecting both types of ``remote'' files.

You're arguing against a single predicate. I have no problem with multiple
predicates, as I stated clearly several times, including yesterday.

My understanding from the beginning has been that accessing files on a network
drive is generally faster than accessing the remote files that are reported
traditionally by `file-remote-p', but that both are generally slower than
accessing a typical local drive. You have confirmed that, so it seems we pretty
much agree now - at least about what happens, if not what to do about it.

This came up because a user of some of my code reported slow access in a
particular context, and that was for files on a Windows network drive. There was
no problem for local files, but, for this context, accessing the network drive
files was "too slow".

While remote files in the traditional sense might typically be slower still, the
point is that both are typically slower than local files, and, depending on the
context, both could be "too slow". Andromeda is orders of magnitude farther than
the sun, but both are too high for me to jump.

I want a way to distinguish the local from both kinds of "remote". (Again, I'm
interested only in time here, not whether the files are actually local or
remote.) If that's via two or three predicates instead of one, I don't mind.

With your help, I cobbled together something that works, for my context, better
than what `file-remote-p' alone gives. I thank you again for your NET USE
suggestion for Windows mapped drives - that helps a lot. I would like Emacs to
deal with this more generally (e.g. not just Windows). I also proposed that the
file-name patterns that `ffap-file-remote-p' tests be incorporated in
`file-remote-p'. That's all.

I described my use case a little bit. I can describe it more if that helps. But
the point is that I'm looking for a quick (local) way to test file names that
will give an idea whether accessing them might be slower than typical local
access.