Mail Archives: cygwin/2005/02/18/09:50:51
On Fri, Feb 18, 2005 at 06:28:19AM -0700, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>According to Corinna Vinschen on 2/18/2005 1:58 AM:
>>
>> The reason for your problem is that Cygwin doesn't check for volume mount
>> points. FWICT, there's a very simple solution for that, calling a specific
>> Windows function (GetVolumePathName) from inside Cygwin.
>>
>> But I'm sure you don't want that. Using this function inside of Cygwin
>> slows down Cygwin incredibly, because that function is staggeringly slow.
>> I called find in medium sized directory trees and find needed about 10
>> times longer to traverse the directory tree than without this function.
>>
>> Sorry, but there's currently no good solution for that.
>
>Both find and coreutils df use the gnulib module mountlist.c to build an
>internal cache of all mount points up front, rather than constantly
>querying if a particular directory is a mount point. Is it not possible
>for cygwin's implementation of getmntent() to also return
>junctions/reparse points as mount table entries, to give an accurate
>picture of all mount points to tools that need it? Mount points don't
>usually change during operation, so cygwin could take the same approach of
>caching all Windows mount points up front at the same time it caches
>cygwin mount points; isn't it possible for such caching to be done once as
>cygwin1.dll initializes and shared, rather than once per process that uses
>cygwin1.dll?
>
>Yes, I know, PTC.
So rather than wait 10 seconds in the case when you are traversing mount
points, you'd rather that every cygwin program was guaranteed to be
delayed by 10 seconds or more at startup? That doesn't sound like a win
to me.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -