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
X-Spam-Check-By: sourceware.org
Message-ID: <4F3ABAEC.40900@cs.utoronto.ca>
Date: Tue, 14 Feb 2012 14:50:04 -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) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: File operations really slow in emacs
References: <4F35C1E0 DOT 2020308 AT cs DOT utoronto DOT ca> <20120211101158 DOT GC9823 AT calimero DOT vinschen DOT de> <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>
In-Reply-To: <20120214175735.GH25918@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

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 would be both 
fast and give enough information to keep stat() happy; readdir() would 
still be out of luck tho.

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