[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: testing for a remote file to include file on aWindows mappeddrive

From: Drew Adams
Subject: RE: testing for a remote file to include file on aWindows mappeddrive
Date: Mon, 21 Apr 2008 01:15:52 -0700

> > _I_ sure wish it did.  I like using global-auto-revert-mode,
> > but that can make Emacs hang when it checks a remote file.
> > And since file-remote-p doesn't give the right answer ...
> Is a file on a CDROM device that needs to spin up on every access
> file-remote-p?

We agree that we might need other test functions, such as Michael suggested.

But as long as the agreed-upon purpose of `file-remote-p' is to let you avoid an
access performance cost, that can be the place to incorporate such info.

IOW, either we add other test functions, as Michael suggested with
`file-mounted-p', and you then test with (or ...) to see if there is a possible
slowdown, or we put the tests into `file-remote-p' and we recognize that the
name is not accurate. Or we roll all the tests into some other function (as I
tried to do with `my-remote-file'), say, `slow-access-file-p'.

The expressed need is to know whether accessing a file with a given name might
be significantly slower than accessing a local file on an ordinary drive etc.

Some of those terms might be vague, but the general idea is clear: We want to
get a performance assessment from the file name (perhaps also locally checking
known mounts, mapped drives etc.) - without incurring a significant performance
penalty for the test itself. 

A boolean estimate is probably enough: possible performance hit vs probably
fast. How that is done, and whether it indicates that the file is remote or on a
slow local drive or whatever, I really don't care (but we might care, in some

For some uses, some people might want more than a boolean - a time estimate, so
they can judge "fast enough" for some particular use. But for myself, now,
classifying the file names into two groups (probably fast, possibly slow) is

reply via email to

[Prev in Thread] Current Thread [Next in Thread]