On Jan 11 19:13, L. A. Walsh wrote: > Corinna Vinschen wrote: > > I know why this happens but I don't see an easy way around that. > > Basically the problem is that Cygwin has no control over the OS mount > > points (i. e., drive letter mapping and volume ireparse points). Given > > that, apart from C: maybe, the drive letter mapping can change any time, > > Cygwin doesn't cache the information but requests it every time it needs > > it. This includes information required in /proc/mounts, here basically > > the FS type. This in turn requires to open a handle to the FS, which > > may result in the observed hang. > ---- > Thanks for the explanation. Looking at my ".bashrc", > I can't figure out why needed this so I can comment it out. > However, as an "aside", I'm not sure why my workaround > didn't work...though I might guess. > > I tried using 'timeout' from 'coreutils-8.23-4' like: > readarray -t proc_mounts< <(timeout -k 2 1 cat /proc/mounts) > > I had hoped that w/cat hanging, timeout waits 1 second (2nd > number), and if no response after the #secs after -k (2) > then it's suppose to try to kill it. > > I'm guessing that since it's a cygwin signal, it is probably > waiting for Win to return to cygwin land so cygwin can > process the signal -- but since it's off in la la land, > cygwin doesn't get a chance to clean up.
Exactly. The hanging call is just some NtOpenFile call on the filesystem. The timeout is an unfortunate effect of accessing a remote drive. One problem here is that Cygwin doesn't support interrupting of synchroneous Windows I/O calls from the signal handler. That's something I'm planning to do at one point, but don't hold your breath. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
