This is the mail archive of the
mailing list for the Cygwin project.
Re: File operations really slow in emacs
On 14/02/2012 12:57 PM, Corinna Vinschen wrote:
On Feb 14 12:46, Ryan Johnson wrote:
Heisenburg? Impossible to know both what SMB share a mount points to and
whether it's currently connected?
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?
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 would be both
fast and give enough information to keep stat() happy; readdir() would
still be out of luck tho.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple