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.

See my reply to your other mail.

Regardless of where it is and what is called, we need some quick estimate of
whether accessing a file will be relatively fast or slow. 

And the purpose of file-remote-p was decided (in the earlier thread) to be as I
said above: to give a quick estimate with the aim of being able to avoid a
performance penalty. IOW, as long as we don't have other functions to do that,
`file-remote-p' is the place to do it.

I have no objection to renaming things or adding another function that takes
other things into account. My aim is the stated aim of file-remote-p (as decided
in the earlier thread): to avoid trying to access (e.g. match name against
existing files) files when that access might be slow. I need at least a binary
determination: fast vs slow.