This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: binmode for UNC paths


On Thu, Oct 11, 2001 at 11:32:04PM +0400, egor duda wrote:
>Hi!
>
>Thursday, 11 October, 2001 Christopher Faylor cgf@redhat.com wrote:
>
>CF> I actually don't like either method.  binmode has two uses -- devices and
>CF> unknown disk files that are opened via redirection.
>
>CF> /cygdrive settings are for files accessed through the /cygdrive prefix.
>
>it may look like a play with words but /cygdrive is just a thing
>created by "internal kernel automounter". but //server/share is, imho,
>just the same thing!

I guess we'll just have to disagree.  I don't think that this is the
same thing at all.

>CF> Neither seems like the correct solution to me.
>
>CF> If this was UNIX, we wouldn't have to worry about this (and not just
>CF> because UNIX doesn't worry about binmode/textmode foolishness).  In
>CF> UNIX, you'd mount the directory.
>
>or UNIX automounter would do that for you. what we're talking about
>is, basically, a feature for "automounter configuration".

The UNIX automounter would have a file somewhere which controlled this
type of behavior specifically.  I am not aware of an automounter which
let you automatically mount any host in your domain but I don't use this
at all, so maybe this is a possibility.

At the very least, automount requires setup and consideration with a
specific utility called "automount".  IMO, /cygdrive is not a similarly
intuitive place to place this consideration.

>the problem is that "network neighborhood" is much more volatile
>comparing to local drive mappings. it's possible to maintain the
>settings for the latter, but sometimes quite hard to maintain the
>settings for the former.

Actually, I wouldn't say that it was "much" more volatile.  I imagine
that it is slightly more volatile.  Actually, my local system
configuration hasn't changed in a long long time but I have added
disks over the years, so my /cygdrive's have changed.  Of course,
this changes my network neighborhood, too.  Maybe that's what you
meant...

>'mount -s -b --settings //*' will solve the problem fine, but i still
>can't see the need to have two different set of settings for "local
>automounted paths" and "remote automounted paths". If someone really
>needs this, it'd surely possible to implement.

If you want to think of this as "auto mounting" then we should generalize
an interface that deals with "auto mounting" and remove the /cygdrive
consideration from it.

Ironically, Geoff Noer's original implementation of the /cygdrive
concept called this stuff "automounts".  I don't really think of them as
"auto mounts" as much as drive mappings, though, so I changed most of
the places which referred to /cygdrive in that way.

In my mind, an automount is something that is not there until it is
referenced.  Your C: drive is always there, mounted on your disk.  A
network share *is* more like an automount since, until you reference the
share, it is possible that Windows knows nothing about it.

Maybe it is a subtle semantic game but I wouldn't be surprised to hear
that most people do not think of /cygdrive as some sort of "automatic
mount".  They probably think it is a pain in the rear, actually, but
that's another story...

Hmm.  Maybe we could unite both concepts under the "pain in the rear"
umbrella.

>CF> I think it might be simpler to just change remote shares to use
>CF> "automode".
>
>this wouldn't work in all cases.

Well, that's sort of a given with automode.  It's a compromise.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]