Delivered-To:	listarch-cygwin-developers AT sourceware DOT cygnus DOT com
From:	Christopher Faylor <cgf AT cygnus DOT com>
Message-ID:	<19990201202319.B29435@cygnus.com>
Date:	Mon, 1 Feb 1999 20:23:19 -0500
To:	Geoffrey Noer <noer AT cygnus DOT com>, DJ Delorie <dj AT delorie DOT com>
Cc:	fujieda AT jaist DOT ac DOT jp, cygwin32-developers AT cygnus DOT com
Subject:	Re: Mount improvements finished
References:	<19990127144716 DOT B9708 AT cygnus DOT com> <wksocs9747 DOT fsf AT indra DOT will DOT or DOT jp> <199901310017 DOT TAA00964 AT envy DOT delorie DOT com> <19990201011721 DOT A18257 AT cygnus DOT com>
Mime-Version:	1.0
X-Mailer:	Mutt 0.93i
In-Reply-To:	<19990201011721.A18257@cygnus.com>; from Geoffrey Noer on Mon, Feb 01, 1999 at 01:17:21AM -0800
Sender:	owner-cygwin32-developers AT cygnus DOT com

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.

- Raw text -