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

[Eli Zaretskii <eliz@gnu.org>]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Sat, 26 Jan 2008 09:57:17 -0800
> 
> > Accessing a remote file via the normal filesystem API (which is what
> > happens with remote drives and NFS-mounted volumes) is several orders
> > of magnitude faster than Tramp or ange-ftp.  So I find it hard to
> > believe that the same primitive would fulfill both of these needs.
> 
> I didn't say anything about using "the same primitive".

Well, you repeatedly talked about file-remote-p, so it's easy to err
like I did.  Sorry.

> Perhaps the performance depends also on the particular remote machine and
> its connectivity, VPN, firewall, etc. I don't know, and I don't care. For
> me, it does no good to argue that accessing a mapped network drive is
> "several orders of magnitude" faster than using Tramp or FTP. It is not
> *noticeably* faster in my case, and, more importantly, it is much, much
> slower for me than accessing a local file. No numbers; only perception. It
> might be orders of magnitude faster, but it is too slow for me.
> 
> Trust me - If a file name is likely to represent a file that is on a network
> drive, then I usually want to treat it as the name of a remote file in terms
> of avoiding unnecessary access. That's all.

You seem to perceive my questions as some kind of questioning the
validity of your reports.  That is a far cry from what I meant.

If this problem is something specific to your setup, you could devise
your own private solution: after all, you likely know what drives are
connected to remote machines in your case.  (Btw, you never responded
to my suggestion to try the output of "net use".)

But if you are asking for an Emacs primitive to solve this, then
please do at least some research and provide the details and
quantitative results about the problem.  At the very least, those
numbers will be used when various possible solutions are evaluated by
those who might work on this problem, as the baseline to measure the
speedup of those solutions.  It is also quite probable that we will
want to compare your results with ours, as we try to find the
reason(s) for the slowdown.  "Trust me" will not help us do that.

While you might not care about the reasons, we who maintain the
Windows port surely do care, because without understanding those
reasons, we cannot devise the right solution.  For example, while you
think that the reason is the fact that these files are on a remote
machine, the real reason might be something entirely different, in
which case the GetDriveType call is not going to solve the problem for
you.