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: <jasonr@gnu.org>, <michael.albinus@gmx.de>, <monnier@iro.umontreal.ca>,
>         <emacs-devel@gnu.org>
> Date: Mon, 21 Apr 2008 21:43:26 -0700
> 
> > > > > 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.
> > > > 
> > > > No one in their right minds will mount a drive half the 
> > > > globe away via NFS or similar networking filesystem.
> > > > They will always use something like Tramp or ftp.  So
> > > > this problem simply does not exist in practice.
> > >
> > > I didn't say anything about NFS or similar; I mentioned 
> > > Windows mapped network drives.
> > 
> > Same same.  Note that I did say ``or similar networking filesystem''.
> 
> So it makes no sense to map a Windows network drive to a remote UNIX file system
> with SMB.

Only if the drive is ``half the globe away''.

> > > However, accessing a mapped network drive is typically
> > > much slower than accessing a local hard drive (please -
> > > no comments about USB sticks).
> > 
> > That is simply not true in general, even before situations like USB
> > sticks are concerned.  Of course, if you are in the US and the drive
> > is in Asia, that could be true, but that is a very unusual situation.
> 
> According to the network engineers I spoke with today, it is true in general.
> It's about the network properties (software and hardware), not necessarily the
> distance. It makes sense to me, but I'm no networking expert. You win.

I hope this is not just about winning.  Network access is indeed
slower than local hard disk access, but only by small factors (again,
unless the network is extremely slow, which is not what one sees
normally).  By contrast, access to files for which file-remote-p
returns non-nil now is several orders of magnitude slower (10 seconds
is not unusual, vs fraction of a second for a networked file).

Here's a random example, from an XP SP2 machine where I'm typing this.
W: is a networked drive mounted via a corporate network, while D: is a
local drive.  `ls' is a Windows port of GNU ls from Coreutils 6.9:

  D:\usr>timep ls -l test
  total 0
  -rw-rw-rw- 1 P0009057 Domain Users 0 2008-04-22 08:49 foobar
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir1
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir10
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir2
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir3
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir4
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir5
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir6
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir7
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir8
  drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir9

  real    00h00m00.031s
  user    00h00m00.015s
  sys     00h00m00.015s

  D:\usr>timep ls -l w:/
  total 0
  drwxrwxrwx 1 P0009057       None         0 2007-02-14 20:13 Accounting
  drwxrwxrwx 1 P0009057       None         0 2008-04-16 08:25 CTI
  drwxrwxrwx 1 Administrators Domain Users 0 2004-07-21 12:54 Management
  drwxrwxrwx 1 Administrators Domain Users 0 2007-03-25 11:45 Marketing
  drwxrwxrwx 1 P0009057       None         0 2008-02-20 10:41 Nob
  drwxrwxrwx 1 Administrators Domain Users 0 2007-06-20 13:53 Projects
  drwxrwxrwx 1 Administrators Domain Users 0 2008-03-24 14:46 RealTime
  drwxrwxrwx 1 P0009057       None         0 2007-06-28 11:22 SIMTECH
  drwxrwxrwx 1 P0009057       None         0 2007-10-24 15:48 Telecom Solutions
  drwxrwxrwx 1 Administrators Domain Users 0 2003-10-26 16:19 TSG-QA
  drwxrwxrwx 1 Administrators Domain Users 0 2008-04-06 11:44 TSG_Marketing Material

  real    00h00m00.109s
  user    00h00m00.015s
  sys     00h00m00.031s

This is a 3-fold slowdown for a networked volume, and accessing 11
directories with a plethora of file I/O APIs still takes a fraction of
a second.

By contrast, just typing "plink fencepost.gnu.org 'ls -l test'" to
produce a listing of a directory on a drive ``half a globe away'' from
where I physically sit takes 4 seconds, and that's even without the
Tramp overhead that could well double or even triple that time.  So
access to what we now call ``remote'' files is 2 orders of magnitude
slower than accessing a local file.

Given these numbers, I fail to see how the same simple predicate can
satisfy the need for detecting both types of ``remote'' files.