This is the mail archive of the
mailing list for the Cygwin project.
Re: File operations really slow in emacs
On 14/02/2012 10:17 AM, Corinna Vinschen wrote:
On Feb 14 09:44, Ryan Johnson wrote:
I was also thinking about this readdir vs. stat thing after my last
post... I've never noticed `ls /cygdrive` being a problem. This is why I
thought it was emacs at first, and why I didn't notice z: at first.
Strangely, bash auto-completion for `/cygdrive/^I` sometimes is fast and
sometimes is slow.
On 14/02/2012 8:52 AM, Corinna Vinschen wrote:
On Feb 14 08:37, Ryan Johnson wrote:
This looks suspicious. I assume you're suffering from SMB network
is there a workaround? Neither "always run elevated" nor "always
keep all network drives mounted" seems like a reasonable
What are you expecting? Was my reply in
http://cygwin.com/ml/cygwin/2012-02/msg00375.html not sufficient?
The reply explains why running elevated avoids the problem --
apparently a side-effect of Windows' user token handling.
It does not explain why it's a good idea to always run elevated to
get a side effect that compensates for bad behavior which is
arguably a bug (though that's what I'm doing right now for lack of a
better option -- I often work off-grid, so I can't always have all
network drives mapped).
AFAICT, `stat /cydrive` runs into trouble because it enumerates all
drive letters using GetFileAttributes, and only counts local drives
as "links" to the "directory" : 2 + ndrives - nfloppies - nnonlocal.
That's only for stat and, yes, that can be removed and the link
set to 1, as for disk-based directories.
But that's not all. GetFileAttributes is called in readdir as well, and
if it works, the subsequent code tries to open the drive and fetch the
inode number. The inode number is important because otherwise find(1)
and other tools might print confused warnings.
So, even if we fix fstat, it doesn't solve the problem for readdir. The
GetFileAttributes call is obviously supposed to find out if the drive is
accessible. If not, it's omitted from the cygdrive dir. Unfortunately...
Does anybody know a system call which allows to fetch the network drive
state (connected/not connected) without a billion microsecond timeout?
I was going to suggest doing in fhandler_cygdrive::fstat whatever
fhandler_cygdrive::readdir does, but source diving confirms that the two
functions do essentially the same thing (huh???). Even more strangely,
none of my open terminals exhibits the problem right this minute, even
though some of them have been open this whole time. There must be some
external factor that makes Windows sometimes try to connect those drives
and sometimes not.
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, and everything in
/cygdrive should be mounted (if not, fhandler_cygdrive::readdir and stat
are both broken).
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple