This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: File operations really slow in emacs

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.



-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]