This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project. See the Cygwin home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: Mount improvements finished

I just checked in a change that causes the mounts to be
internally sorted by decreasing length of the win32 path.

That seems to solve this particular problem.

cgf

On Mon, Feb 01, 1999 at 01:17:21AM -0800, Geoffrey Noer wrote:
>On Sat, Jan 30, 1999, DJ Delorie wrote:
>> > /cygdrive/d $ mount
>> > Device              Directory           Type         Flags
>> > d:                  /cygdrive/d         user,auto    textmode
>> > D:\binary           /binary             user         binmode
>> > C:                  /                   user         binmode
>> 
>> Geoff - is this list sorted in the same order we scan them?  
>
>Yes it is.  (Mount.exe just does repeated getmntents until there
>aren't any mount points left to print; that reflects the order of the
>internal list of mounts).
>
>> If so, we
>> need to store it sorted both by posix path and separately by win32
>> path.  When we convert from a win32 path to a posix path, we need to
>> search the *win32* paths longest first.  Simply reusing the list
>> sorted by posix path lengths isn't going to work.
>
>Keep in mind that I haven't actually changed the way the mount table is
>sorted from the old way of handling mounts (except a change to make
>user mounts take priority over system mounts when sorting).  Of course
>we can change it if we want to; I need to think about this some more...
>
>> I also suggest that mount.exe print the paths sorted by posix paths
>> (alphabetical, not by length, case insensitive), so that "/" is first.
>
>Why?  I think it's useful to see them in the order of evaluation.
>
>> > So I propose specifically setting the priority of automounts lower
>> > than normal one like the following patch.
>> 
>> While this would avoid the problem it's not the right solution, since
>> it doesn't fix the problem as it is, which I think is caused by the
>> way we sort and scan the internal tables (it's an optimization).
>
>I'm not so sure.  I tend to think that it would be a good thing if
>paths converted to posix would choose a non-automount mount point
>before automounts.