Mail Archives: cygwin/2012/02/16/08:18:39
Hi Corinna,
On 16/02/2012 6:09 AM, Corinna Vinschen wrote:
> On Feb 15 10:24, Corinna Vinschen wrote:
>> On Feb 14 14:50, Ryan Johnson wrote:
>>> Heisenburg? Impossible to know both what SMB share a mount points to
>>> and whether it's currently connected?
> Almost. You have to access the share to find out if it is really
> connected because the information returned from NetUseGetInfo that the
> drive is disconnected could be outdated. This is deep within the way
> SMB works. Either you wait up to, I'm not quite sure, 60 minutes I
> think, or you just plunge into the drive and try to access it and
> potentially suffer network timeouts.
>
>>> 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.
> I just applied a patch which calls NetUseGetInfo on SMB drives in
> the cygdrive::readdir call. As I mentioned above, if the function
> returns OK, we fetch the inode number. If the function returns
> "Disconnected", we just omit the drive from the cygdrive directory.
> If the drive is available again, it might not be noticed by the
> NetUseGetInfo function for a long while. But as soon as you access
> the drive successfully, the info will be updated in the OS, and the
> NetUseGetInfo function will happily return OK again. This new
> behaviour is not a swiss army knife since that's impossible with
> SMB. But it might be better suited then the former code. I'm
> just going to create a new snapshot. Please test.
That sounds like a reasonable approach (how do you figure out which
drive letters are network drives before calling NetUseGetInfo, btw? That
would allow stat /cygdrive to return proper link counts).
Unfortunately, the fingerprint reader on my machine is buggy and
sometimes crashes winlogon... machine technically still running but
utterly inaccessible; I've not been able to repro since rebooting.
I'd really like to know what caused the slowdowns before... I kind of
doubt the fingerprint reader was at fault.
BTW, this latency problem has been observed before [1]. There's no real
solution, but one reader suggested using a second thread to call
CancelSynchronousIo if you lose patience before the call returns. From
the docs on MSDN[2], though, there's a long list of pretty icky caveats
that may limit its usefulness in practice. Others [3] have suggested
that calling FindFirstFile first eliminates the latency, though I have
to wonder if that would actually be helpful.
[1]
http://stackoverflow.com/questions/1142080/how-to-avoid-network-stalls-in-getfileattributes
[2]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363789%28v=vs.85%29.aspx
[3]
http://embarcadero.newsgroups.archived.at/public.delphi.nativeapi/201004/1004223088.html
Ryan
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -