From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2807 invoked by alias); 3 Apr 2008 15:16:42 -0000 Received: (qmail 2774 invoked by uid 22791); 3 Apr 2008 15:16:40 -0000 X-Spam-Check-By: sourceware.org Received: from ACCESS1.CIMS.NYU.EDU (HELO access1.cims.nyu.edu) (128.122.81.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 15:16:08 +0000 Received: from localhost (localhost [127.0.0.1]) by access1.cims.nyu.edu (8.13.8+Sun/8.13.8) with ESMTP id m33FG637008491; Thu, 3 Apr 2008 11:16:06 -0400 (EDT) Date: Thu, 03 Apr 2008 15:16:00 -0000 From: Igor Peshansky Reply-To: cygwin-developers@cygwin.com To: cygwin-developers@cygwin.com cc: cygwin-apps@cygwin.com Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area In-Reply-To: <20080403141958.GM4468@calimero.vinschen.de> Message-ID: 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> <20080403141958.GM4468@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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/msg00041.txt.bz2 On Thu, 3 Apr 2008, Corinna Vinschen wrote: > [snip] > > >>> 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. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. > [snip] > > 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. Umm, i don't see how that follows. cygrunsrv can easily reside in /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked from the shell, and (b) when cygrunsrv installs the services, it adds /bin to the PATH in the service environment. > Right now I must admit that I prectically don't care if my packages > install the binaries in /bin or /usr/bin. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, "kill", "shutdown", etc. > > >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?!? It is, IMHO. > > >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. That, and also to allow completely disjoint Cygwin installations for different users (where the mount table would otherwise be shared). But this effect can also be accomplished with /etc/fstab (one per installation). > However, that's not really necessary anymore with /etc/fstab. > So I agree, we can simply get rid of fstab.$SID. Yes, that reasoning is mostly correct. However, some packages (like Cygwin/X) apparently assume a single-user installation, and create sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, makes the default startup scripts insufficient to allow multiple users to run Cygwin/X sessions simultaneously, unless that shared location is overridden in a per-user manner (e.g., through user mounts). So, until we figure out how to solve that issue, user mounts are actually userful. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ pechtcha@cs.nyu.edu | igor@watson.ibm.com ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it." -- Rabbi Hillel