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

[Drew Adams]

> > As you said, the purpose of file-remote-p is to determine, 
> > without the cost of a remote access, whether a file name
> > represents a remote file. The aim in using it
> > is to be able to know that a file is remote, so you might 
> > then avoid the cost of accessing it.
> 
> As mentioned in the earlier thread, remoteness is not a reliable 
> indicator of speed. You can have fast remote drives and slow local 
> drives. Maybe in the days of 10Mbps ethernet it was still 
> reasonable to assume that networked drives were slow, but with gigabit 
> ethernet you'd be hard pressed to notice a performance difference
> between a networked and local drive.

That might be, but IIRC, the stated purpose of `file-remote-p' (from the earlier
thread) is to let you know that a file is remote _so that you can choose to
avoid accessing it_ if you want.

There was some discussion of whether `file-remote-p' should actually try to
access the named file, to know whether it in fact names a readable existing
remote file, and the conclusion was no: It should not itself incur a performance
penalty, but should try other means (e.g. syntactic) to determine whether the
name might represent a remote file. 

But the stated purpose was to be able to avoid then accessing the file if it was
thought to be remote, because that might incur a performance penalty.

IOW, `file-remote-p' might not always be an accurate gauge of access
performance, but it can be better than nothing in some common contexts.

Whether I access a local Windows drive (even a slow one) or a Windows mapped
network drive that happens to be in India, there is a world of difference. Maybe
that difference will diminish tomorrow, but today, at least, there is a big
difference. YMMV.