File operations really slow in emacs

[Ryan Johnson]

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