From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28771 invoked by alias); 3 Apr 2008 14:20:27 -0000 Received: (qmail 28744 invoked by uid 22791); 3 Apr 2008 14:20:23 -0000 X-Spam-Check-By: sourceware.org Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 03 Apr 2008 14:20:03 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 39BD16D430A; Thu, 3 Apr 2008 16:19:58 +0200 (CEST) Date: Thu, 03 Apr 2008 14:20:00 -0000 From: Corinna Vinschen To: cygwin-apps@cygwin.com, cygwin-developers@cygwin.com Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area Message-ID: <20080403141958.GM4468@calimero.vinschen.de> Mail-Followup-To: cygwin-apps@cygwin.com, cygwin-developers@cygwin.com References: <20080402123551.GB4468@calimero.vinschen.de> <20080402174556.GI4468@calimero.vinschen.de> <47F40F16.8080303@cwilson.fastmail.fm> <20080403094220.GA21673@calimero.vinschen.de> <20080403135620.GA9219@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080403135620.GA9219@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2008-04/txt/msg00040.txt.bz2 On Apr 3 09:56, Christopher Faylor wrote: > On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: > > - Do we drop registry mount points and store mount points in future > > in fstab-like files as, say, /etc/fstab (system mount points) and > > ~/.fstab (user mount points)? > > > >Having said that... > > FWIW: ~/.fstab - No I don't think that's as easily implementable as having such a file in /etc anyway, but you're making an important note below, so, see there. > /etc/fstab - Yes and get rid of the registry entirely ACK. The reason I implemented this with using the registry as a fallback is for easier testing. The idea is that we (developers and maintainers) can start to use the fstab approach, while normal users on the Cygwin list, who are just curious, still can run a snapshot in their otherwise unchanged environment. > >On Apr 2 17:56, Charles Wilson wrote: > >> Corinna Vinschen wrote: > >>> Get own path ==> C:\\cygwin\\bin\\cygwin1.dll > >>> Where's fstab? ==> C:\\cygwin\\etc\\fstab > >> > >> So, it implicitly computes where / is? > > > >No, it doesn't. It just snips away the last two path components and > >tacks the etc/fstab string on. Plus the .$SID to get the user mounts. > > > >After the mount points have been read, root can potentially be > >somewhere else entirely. > > I think that's the right way to handle this. That puzzles me a bit, because of what you write below. > >>> these are my fstab files: > >>> $ cat /etc/fstab > >>> C:\cygwin / ntfs binary 0 0 > >> > >> Which means that the line above really ought to match the computed '/', or > >> bad things might happen, right? If so, then it is redundant to specify it > >> here. Perhaps this should just be autocomputed...since the fstype and last > >> two elements are ignored. > > > >Yes, I thought about this, too. It doesn't really seem to make much > >sense to redefine /. As for /usr/bin and /usr/lib, these paths are > >not inherently defined by the DLL. They exist because a decision > >has been made how to create a Cygwin installation in the net distro. > >This could be changed in future, or our internal Red Hat release > >could need another layout. There's no reason to couple this distro > >decision to the DLL, IMHO. > > For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <> > /usr/lib. The rationale for keeping those linked no longer applies in > the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. > >Or simply > > > > root / ntfs binary 0 0 > > > >and stick to /usr/bin and /usr/lib as they are today. > > I think something like an automount is needed since it would be nice to > eventually generalize the cygdrive stuff and we don't want to explicitly > mount a: - z: So, maybe we could consider a linux-like solution to > accomplish this although I really don't like automount. I'm not sure I understand this, that's why I was puzzled above. Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? > >I have the vague feeling it would be sufficient to install only a > >/etc/fstab, even in "just me" mode, though. The fstab.$SID file is > >only necessary in multi-user installations, IMHO. > > Why do we need a fstab.$SID and linux doesn't need this? Let me think... I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure "just me" installation in a restricted environment. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. > >Another problem is that the 1.7 mount(1) still creates the mount entries > >in the registry. This should be removed, if we stick to the file based > >approach. mount would only create temporary mount points which are > >only valid in this single session, until the last Cygwin process in this > >session exits. A bit like a reboot on Linux :) > > On XP it should be possible to make it so that the mounts last until > reboot. If we can do that I think it would be ideal. How? The mount points are bound to the existance of the shared memory they reside in. This shared mem disappears when the last Cygwin process in a session exits. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat