This is the mail archive of the
mailing list for the Cygwin project.
Re: File operations really slow in emacs
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.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple