From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3521 invoked by alias); 3 Apr 2008 13:56:50 -0000 Received: (qmail 3497 invoked by uid 22791); 3 Apr 2008 13:56:47 -0000 X-Spam-Check-By: sourceware.org Received: from pool-72-74-94-32.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (72.74.94.32) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Apr 2008 13:56:22 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id 98C0B17F577; Thu, 3 Apr 2008 09:56:20 -0400 (EDT) Date: Thu, 03 Apr 2008 13:56:00 -0000 From: Christopher Faylor To: CygWin-Apps , cygwin-developers@cygwin.com Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area Message-ID: <20080403135620.GA9219@ednor.casa.cgf.cx> Reply-To: cygwin-apps@cygwin.com, cygwin-developers@cygwin.com Mail-Followup-To: CygWin-Apps , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080403094220.GA21673@calimero.vinschen.de> 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/msg00039.txt.bz2 On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: >For a start, please note that this patch is just preliminary. > >The actual problem is still one of the problems I noted in my mail >http://cygwin.com/ml/cygwin-developers/2008-03/msg00000.html, to which I >didn't get a reply, except from Brian. > > - The POSIX path of mount points is restricted to 256 characters. > That's because it's used as the value name of a registry value and > value names are restricted to (surprise!) 256 chars. A decision > and, perhaps, coding has to be done: > > - Do we stick to this restriction? > - Do we introduce a new mount point storage in the registry? > - 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 /etc/fstab - Yes and get rid of the registry entirely >On Apr 2 17:56, Charles Wilson wrote: >> Corinna Vinschen wrote: >>> I have applied a preliminary patch to Cygwin which allows to load the >>> mount entries from /etc/fstab and /etc/fstab.. If none of >>> these files is available, the DLL falls back to reading the mount points >>> from the registry. >> >> I like this. A lot. > >AOL ;) > >>> Cygwin finds the fstab files by fetching it's own Win32 path and then >>> replacing the last two path components with etc/fstab or >>> etc/fstab., like this: >>> 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. >>> The layout of the fstab file follows the Linux layout. As example, >>> 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. >> [...] >> Maybe there should be "special" rules for the three special autocomputed >> mount points: >> >> # NOTE: the three "magic" auto-computed paths are present >> # in this file strictly so that mount options may be specified. >> C:\This\Path\Is\AutoComputed / ntfs binary 0 0 >> C:\This\Path\Is\AutoComputed /usr/bin ntfs binary 0 0 >> C:\This\Path\Is\AutoComputed /usr/lib ntfs binary 0 0 > >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. >> Oh, and I'm guessing that setup-1.7 should create /etc/fstab if "install >> for all users", and "/etc/fstab.SID" if "just me"? Otherwise, you'll >> clobber the "old" cygwin's registry entries every time you try to update >> your "new" cygwin installation... > >That's right. I think this could be done by a simple postinstall script >which gets called from setup-1.7. Consider a package which comes with >a default /etc/fstab which consists only of the above entry for the root >dir. The script would simply add the /usr/bin and /usr/lib entries. >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? >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. cgf