From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7782 invoked by alias); 5 Apr 2008 06:17:33 -0000 Received: (qmail 7761 invoked by uid 22791); 5 Apr 2008 06:17:32 -0000 X-Spam-Check-By: sourceware.org Received: from bay0-omc3-s13.bay0.hotmail.com (HELO bay0-omc3-s13.bay0.hotmail.com) (65.54.246.213) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 05 Apr 2008 06:17:01 +0000 Received: from BAY105-W49 ([65.54.224.149]) by bay0-omc3-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 23:16:59 -0700 Message-ID: From: Karl M To: , CygWin-Apps Subject: RE: [HEADSUP] Let's start a Cygwin 1.7 release area Date: Sat, 05 Apr 2008 06:17:00 -0000 In-Reply-To: <20080403094220.GA21673@calimero.vinschen.de> References: <20080402123551.GB4468@calimero.vinschen.de> <20080402174556.GI4468@calimero.vinschen.de> <47F40F16.8080303@cwilson.fastmail.fm> <20080403094220.GA21673@calimero.vinschen.de> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes 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/msg00063.txt.bz2 Hi All... I like this!!! > Date: Thu, 3 Apr 2008 11:42:20 +0200 > From: corinna > Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area > > 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... > > 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 =3D=3D> C:\\cygwin\\bin\\cygwin1.dll >>> Where's fstab? =3D=3D> 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. > >>> 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 la= st >> 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. > >> [...] >> 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. > >> 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. For multiple "Just Me" installations? > > 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 :) > >> One little wrinkle that makes switching between two cygwin installations >> difficult: services. Do you >> >> (1) stop/uninstall -- switch-to-other-cygwin -- reinstall/start as part = of >> each switch, or >> >> (2) somehow change each service's target path (and PATH environment >> variable, if the service.exe is not in /bin. For the proposed 1.7.0 you >> have to ensure that the "correct" cygwin1.dll is used), and then restart? >> >> (3) install services under different names for the two installations, and >> just remember to stop all the old ones, before trying to use any tools f= rom >> the "new" installation, and restart the "new" services under their >> alternate installation names? The installation part of this proposal cou= ld >> be automated in the foo-config scripts: >> if cygwin_17 >> then service_name=3Dsshd_17 >> else service_name=3Dsshd >> fi >> etc. > > Consider that a parallel installation is not really for the normal user. > My answer to this question is, whatever is most convenient for you. > Personally I tend to option 3, without the changes in the foo-config > scripts. I'd do the second service installation manually. It's not > that hard. > I think that I prefer (1). I have cygwin-shutdown and cygwin-startup scripts anyway, because it makes stopping and starting to run setup easier...so this is no different. I actually uninstall and reinstall the services in my cygw= in-startup script so that the path gets updated if I install/uninstall any other softw= are. I have one fewer thing to remember that way. > ...Karl _________________________________________________________________ Get in touch in an instant. Get Windows Live Messenger now. http://www.windowslive.com/messenger/overview.html?ocid=3DTXT_TAGLM_WL_Refr= esh_getintouch_042008