Date: Wed, 15 Feb 2012 10:24:39 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: File operations really slow in emacs
Message-ID: <20120215092439.GM25918@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <4F3910B2.3070905@cs.utoronto.ca> <4F3A63AF.7010905@cs.utoronto.ca> <20120214135246.GA25918@calimero.vinschen.de> <4F3A7357.4010505@cs.utoronto.ca> <20120214151745.GD25918@calimero.vinschen.de> <4F3A81F8.80205@cs.utoronto.ca> <20120214162656.GE25918@calimero.vinschen.de> <4F3A9E01.7000500@cs.utoronto.ca> <20120214175735.GH25918@calimero.vinschen.de> <4F3ABAEC.40900@cs.utoronto.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4F3ABAEC.40900@cs.utoronto.ca>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On Feb 14 14:50, Ryan Johnson wrote:
> On 14/02/2012 12:57 PM, Corinna Vinschen wrote:
> >On Feb 14 12:46, Ryan Johnson wrote:
> >>On 14/02/2012 11:26 AM, Corinna Vinschen wrote:
> >>>On Feb 14 10:47, Ryan Johnson wrote:
> >>>>On 14/02/2012 10:17 AM, Corinna Vinschen wrote:
> >>>>>Does anybody know a system call which allows to fetch the network drive
> >>>>>state (connected/not connected) without a billion microsecond timeout?
> >>>>[...]
> >>>>What if we parsed the mount table instead of calling readdir? I
> >>>>don't know how that's computed, but it's never been a performance
> >>>>problem, it only shows drives that are actually connected [...]
> >>>What mount table?  Cygwin's?  It calls GetFileAttributes on the drive's
> >>>root dir as well...
> >>This is bizarre... what would cause calls to the same Windows API
> >>function behave so differently when called by stat vs ls vs
> >>bash-autocomplete? I'm happy to accept that there's some weirdness
> >>on my box, but I would have expected that weirdness to be consistent
> >>at any given instant in time (either all go slow or all behave
> >>normally).
> >SMB just is not consistent.  More often than not the timing behaviour is
> >just plain puzzeling.  And, btw., in *my* testing I got hangs in mount
> >as well if I disabled the remote share.  But only once.  Subsequent
> >calls were fast.  And after enabling the remote share, mount happily
> >ignored that fact for about a minute or so.  Caching, anybody?
> Heisenburg? Impossible to know both what SMB share a mount points to
> and whether it's currently connected?
> 
> It's really unfortunate Windows doesn't have a GetLocalDrives() or
> GetAccessibleDriveLetters() function. Actually, isn't there a
> function to convert DOS paths to those funky //?/ paths? Maybe that

\\?\ is nothing but a Win32 path prefix which tells the kernel32
routines to omit the step to convert to native NT paths.  The problem is
that the conversion buffers  have a fixed size of MAX_PATH characters,
so Win32 paths without the prefix are restricted to 259 chars.  So
in fact, there's no difference between the paths other than to omit
a conversion step.  Apart from that the paths are equivalent:

  standard Win32        C:\dir\file    \\server\share\file
  "long-path" Win32 \\?\C:\dir\file    \\?\UNC\server\share\file
  native NT         \??\C:\dir\file    \??\UNC\server\share\file

> would be both fast and give enough information to keep stat() happy;

Not at all.  It's all the same file and the underlying NT functions
will do the same in all cases.

But I already changed cygdrive::fstat yesterday to set st_nlinks to 1
without calling GetFileAttributes in a loop.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple