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

[Michael Albinus]

Eli Zaretskii <address@hidden> writes:

>> * file-mounted-p (as working name) returns t, if a file looks like an
>>   ordinary file from the operating system's point of view, but its
>>   physical location is on another machine. Examples are nfs, smbfs or
>>   sshfs mounts under GNU/Linux, or network shares under W32. This
>>   property cannot be detected by file name handler functions. The
>>   implementation shall be in the C core.
>> 
>> These functions are exclusive: file-remote-p and file-mounted-p shall
>> not return t for the same filename. Since one function uses the
>> filename only for checking the result, and the other function uses
>> operating system properties, I don't believe it makes sense to merge
>> them into one function.
>
> 110% agreement.  And, given several good arguments posted by Andreas,
> it sounds like the best implementation for determining whether
> accessing a file is likely to be slow would be a simple alist, set by
> the user, since only the user knows which filesystems on her machine
> cause slowdown.  I don't see how Emacs can determine that by itself
> without actually accessing the file.

I like this idea. Let's forget file-mounted-p; Emacs cannot determine
by itself good enough whether something is fast or slow. And even
"fast" and "slow" depend on the user and her preferences.

Maybe we shall have something like `slow-accessible-files-list', a
list of regexps and predicates which denote file names with slow
access. (Please don't blame me for the name; it could be anything else).

If a file name matches one of the regexps, or a predicate with the
file name as argument returns non-nil, then the access to the file is
regarded as, hmm, slow. It could be something like this:

(defvar slow-accessible-files-list
  '(file-remote-p    ;; All files with file name handler functions.
    "^/media/disk")) ;; My USB stick.

And a function, let's call it `file-slow-accessible-p', might evaluate
that list.

Best regards, Michael.