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

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
> >>normally).
> >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
Red Hat

Problem reports:
Unsubscribe info:

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