X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 15 Feb 2012 10:24:39 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: File operations really slow in emacs
Message-ID: <20120215092439.GM25918@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4F3910B2 DOT 3070905 AT cs DOT utoronto DOT ca> <4F3A63AF DOT 7010905 AT cs DOT utoronto DOT ca> <20120214135246 DOT GA25918 AT calimero DOT vinschen DOT de> <4F3A7357 DOT 4010505 AT cs DOT utoronto DOT ca> <20120214151745 DOT GD25918 AT calimero DOT vinschen DOT de> <4F3A81F8 DOT 80205 AT cs DOT utoronto DOT ca> <20120214162656 DOT GE25918 AT calimero DOT vinschen DOT de> <4F3A9E01 DOT 7000500 AT cs DOT utoronto DOT ca> <20120214175735 DOT GH25918 AT calimero DOT vinschen DOT de> <4F3ABAEC DOT 40900 AT cs DOT utoronto DOT 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 AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT 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