X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.8 required=5.0	tests=AWL,BAYES_00,SPF_NEUTRAL,TO_NO_BRKTS_PCNT
X-Spam-Check-By: sourceware.org
Message-ID: <4F3D01EF.5040203@cs.utoronto.ca>
Date: Thu, 16 Feb 2012 08:17:35 -0500
From: Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: File operations really slow in emacs
References: <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> <20120215092439 DOT GM25918 AT calimero DOT vinschen DOT de> <20120216110944 DOT GE19092 AT calimero DOT vinschen DOT de>
In-Reply-To: <20120216110944.GE19092@calimero.vinschen.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.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

Hi Corinna,

On 16/02/2012 6:09 AM, Corinna Vinschen wrote:
> On Feb 15 10:24, Corinna Vinschen wrote:
>> On Feb 14 14:50, Ryan Johnson wrote:
>>> Heisenburg? Impossible to know both what SMB share a mount points to
>>> and whether it's currently connected?
> Almost.  You have to access the share to find out if it is really
> connected because the information returned from NetUseGetInfo that the
> drive is disconnected could be outdated.  This is deep within the way
> SMB works.  Either you wait up to, I'm not quite sure, 60 minutes I
> think, or you just plunge into the drive and try to access it and
> potentially suffer network timeouts.
>
>>> 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.
> I just applied a patch which calls NetUseGetInfo on SMB drives in
> the cygdrive::readdir call.  As I mentioned above, if the function
> returns OK, we fetch the inode number.  If the function returns
> "Disconnected", we just omit the drive from the cygdrive directory.
> If the drive is available again, it might not be noticed by the
> NetUseGetInfo function for a long while.  But as soon as you access
> the drive successfully, the info will be updated in the OS, and the
> NetUseGetInfo function will happily return OK again.  This new
> behaviour is not a swiss army knife since that's impossible with
> SMB.  But it might be better suited then the former code.  I'm
> just going to create a new snapshot.  Please test.
That sounds like a reasonable approach (how do you figure out which 
drive letters are network drives before calling NetUseGetInfo, btw? That 
would allow stat /cygdrive to return proper link counts).

Unfortunately, the fingerprint reader on my machine is buggy and 
sometimes crashes winlogon... machine technically still running but 
utterly inaccessible; I've not been able to repro since rebooting.

I'd really like to know what caused the slowdowns before... I kind of 
doubt the fingerprint reader was at fault.

BTW, this latency problem has been observed before [1]. There's no real 
solution, but one reader suggested using a second thread to call 
CancelSynchronousIo if you lose patience before the call returns. From 
the docs on MSDN[2], though, there's a long list of pretty icky caveats 
that may limit its usefulness in practice. Others [3] have suggested 
that calling FindFirstFile first eliminates the latency, though I have 
to wonder if that would actually be helpful.

[1] 
http://stackoverflow.com/questions/1142080/how-to-avoid-network-stalls-in-getfileattributes
[2] 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363789%28v=vs.85%29.aspx
[3] 
http://embarcadero.newsgroups.archived.at/public.delphi.nativeapi/201004/1004223088.html

Ryan


--
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