X-Recipient:	archive-cygwin AT delorie DOT com
X-Spam-Check-By:	sourceware.org
Date:	Thu, 16 Feb 2012 14:44:14 +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:	<20120216134414.GG19092@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<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> <4F3D01EF DOT 5040203 AT cs DOT utoronto DOT ca>
MIME-Version:	1.0
In-Reply-To:	<4F3D01EF.5040203@cs.utoronto.ca>
User-Agent:	Mutt/1.5.21 (2010-09-15)
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
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 16 08:17, Ryan Johnson wrote:
> On 16/02/2012 6:09 AM, Corinna Vinschen wrote:
> >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?

http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/mount.cc.diff?cvsroot=src&r1=1.86&r2=1.87

> That would allow stat /cygdrive to return proper link counts).

Nah, that's not needed.  All GNU tools are fine with directories with
link count of 1.  That's what we get from NTFS drives anyway, so why
bother?
 
> 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

Not an option.  CancelSynchronousIo is only available starting with
Vista.  Running the read in a thread and killing the thread if a signal
arrives is probably better.  That's how the network scanning code
for // is implemented.

> Others [3] have suggested that calling FindFirstFile first
> eliminates the latency, though I have to wonder if that would
> actually be helpful.

Not to get the inode number of the share directory.


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

- Raw text -