X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-0.7 required=5.0	tests=AWL,BAYES_00,SPF_NEUTRAL
X-Spam-Check-By: sourceware.org
Message-ID: <4F3A81F8.80205@cs.utoronto.ca>
Date: Tue, 14 Feb 2012 10:47: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>
In-Reply-To: <20120214151745.GD25918@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 10:17 AM, Corinna Vinschen wrote:
> On Feb 14 09:44, Ryan Johnson wrote:
>> On 14/02/2012 8:52 AM, Corinna Vinschen wrote:
>>> On Feb 14 08:37, Ryan Johnson wrote:
>>>>>>> (\??\C:\cygwin\cygdrive,0x28BB68)
>>>>>>    ^^^^^^^^^^^^^^^^^^^^^^^
>>>>>>    This looks suspicious.  I assume you're suffering from SMB network
>>>>>>    scanning.
>>>>> is there a workaround? Neither "always run elevated" nor "always
>>>>> keep all network drives mounted" seems like a reasonable
>>>>> requirement
>>> What are you expecting?  Was my reply in
>>> http://cygwin.com/ml/cygwin/2012-02/msg00375.html not sufficient?
>> The reply explains why running elevated avoids the problem --
>> apparently a side-effect of Windows' user token handling.
>>
>> It does not explain why it's a good idea to always run elevated to
>> get a side effect that compensates for bad behavior which is
>> arguably a bug (though that's what I'm doing right now for lack of a
>> better option -- I often work off-grid, so I can't always have all
>> network drives mapped).
>>
>> AFAICT, `stat /cydrive` runs into trouble because it enumerates all
>> drive letters using GetFileAttributes, and only counts local drives
>> as "links" to the "directory" : 2 + ndrives - nfloppies - nnonlocal.
> That's only for stat and, yes, that can be removed and the link
> set to 1, as for disk-based directories.
>
> But that's not all.  GetFileAttributes is called in readdir as well, and
> if it works, the subsequent code tries to open the drive and fetch the
> inode number.  The inode number is important because otherwise find(1)
> and other tools might print confused warnings.
>
> So, even if we fix fstat, it doesn't solve the problem for readdir.  The
> GetFileAttributes call is obviously supposed to find out if the drive is
> accessible.  If not, it's omitted from the cygdrive dir.  Unfortunately...
>
> Does anybody know a system call which allows to fetch the network drive
> state (connected/not connected) without a billion microsecond timeout?
I was also thinking about this readdir vs. stat thing after my last 
post... I've never noticed `ls /cygdrive` being a problem. This is why I 
thought it was emacs at first, and why I didn't notice z: at first. 
Strangely, bash auto-completion for `/cygdrive/^I` sometimes is fast and 
sometimes is slow.

I was going to suggest doing in fhandler_cygdrive::fstat whatever 
fhandler_cygdrive::readdir does, but source diving confirms that the two 
functions do essentially the same thing (huh???). Even more strangely, 
none of my open terminals exhibits the problem right this minute, even 
though some of them have been open this whole time. There must be some 
external factor that makes Windows sometimes try to connect those drives 
and sometimes not.

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, and everything in 
/cygdrive should be mounted (if not, fhandler_cygdrive::readdir and stat 
are both broken).

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