This is the mail archive of the cygwin-developers 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]
Other format: [Raw text]

Re: More: [1.7] packaging problem? Both /usr/bin/ and /usr/lib/ are non-empty


On May 13 12:15, Christopher Faylor wrote:
> On Wed, May 13, 2009 at 10:56:58AM +0200, Corinna Vinschen wrote:
> >On May 12 23:02, Christopher Faylor wrote:
> >> I've called what we do with '/' "immutable".  An immutable mount setting
> >> needs to be overridden with an "override" option.
> >> 
> >> I've also marked all of the automatic mounts with a ",auto" to make it
> >> clear that Cygwin is creating them automatically.  I also added this
> >> to cygdrive mounts.
> >
> >fillout_mntent shouldn't do that.  "auto" and "immutable" are internal
> >flags, not valid mount options.  If fillout_mntent adds them to mnt_opts
> >they will be printed by mount(1), which is not a good idea if you use
> >the `mount -m' command to generate an /etc/fstab output.
> 
> I thought it was nice to be able to see which files came into being
> because of a Cygwin decision and which were called for specifically.  Linux
> adds "stuff" in that field which wasn't specified on the command line.
> 
> But, regarding, "mount -m": It looks like more mount work is required
> there since we don't want mount -m to generate mount commands that will
> fail (as in the case of root) or to force a mount of /usr/lib when it
> isn't necessary.  The ",auto" would be a nice clue about that.  We could
> just have mount ignore that option like linux's mount does with some
> options that show up in its mount output.

Ok, sure.  Are you going to do that?

> >> Oh, and one additional thing that I did was allow the use of -o nouser
> >> as a mount option.  Was there a reason why we disabled that for 1.7?
> >
> >Yes.  The nouser option doesn't make sense for the mount command because
> >you can't override a nouser mount point with the mount command anyway.
> >Every mount point created by mount is a user mount point.
> 
> That is exactly what I changed.  Since linux doesn't have the concept of
> a "user" mount, it seems counterintuitive not to be able for a
> sufficiently privileged user to be able to update a "system" mount
> without needing to change /etc/fstab and restarting every Cygwin process.

But that still doesn't make sense.  The idea is that system (or nouser)
mount points are unchangeable within a session.  The mount points you
create with mount are valid inside of a session only anyway, and the
user typically should not override what the system admin has set as
unchangable by the user.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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