This is the mail archive of the
mailing list for the Cygwin project.
Re: File operations really slow in emacs
On Feb 14 14:50, Ryan Johnson wrote:
> On 14/02/2012 12:57 PM, Corinna Vinschen wrote:
> >On Feb 14 12:46, Ryan Johnson wrote:
> >>On 14/02/2012 11:26 AM, Corinna Vinschen wrote:
> >>>On Feb 14 10:47, Ryan Johnson wrote:
> >>>>On 14/02/2012 10:17 AM, Corinna Vinschen wrote:
> >>>>>Does anybody know a system call which allows to fetch the network drive
> >>>>>state (connected/not connected) without a billion microsecond timeout?
> >>>>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 [...]
> >>>What mount table? Cygwin's? It calls GetFileAttributes on the drive's
> >>>root dir as well...
> >>This is bizarre... what would cause calls to the same Windows API
> >>function behave so differently when called by stat vs ls vs
> >>bash-autocomplete? I'm happy to accept that there's some weirdness
> >>on my box, but I would have expected that weirdness to be consistent
> >>at any given instant in time (either all go slow or all behave
> >SMB just is not consistent. More often than not the timing behaviour is
> >just plain puzzeling. And, btw., in *my* testing I got hangs in mount
> >as well if I disabled the remote share. But only once. Subsequent
> >calls were fast. And after enabling the remote share, mount happily
> >ignored that fact for about a minute or so. Caching, anybody?
> Heisenburg? Impossible to know both what SMB share a mount points to
> and whether it's currently connected?
> 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.
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