X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,BAYES_40,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Message-ID: <4C22D688.5010809@comcast.net> Date: Wed, 23 Jun 2010 23:52:40 -0400 From: Ken User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 SeaMonkey/2.0.3; Firefox/3.6.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: cygwin 1.7.5, 'id -ng' fails when /etc/group is a symlink Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com >> Since I have to manage the Win XP side for the foreseeable future, it >> appears that I will have to adopt another methodology to centrally manage >> these files due to the new 1.7x symlink implementation. > >Just so that there's no misconception. Your problem has nothing to do >with the way Cygwin handles symlinks. > >What we're talking about is a certain problem at an early stage >in Cygwin startup. > >For the Cygwin POSIX path handling to work, we need the content of >/etc/fstab and the content of /etc/fstab.d/$USER, otherwise we don't >have a mount table. To access /etc/fstab.d/$USER we also need the >content of /etc/passwd. Obviously, since we didn't read /etc/fstab >and friends yet, we don't have a mount table and thus we don't have >POSIX paths and, consequentially, no symlink handling. As soon as >the aforementioned three files have been read, the POSIX path >handling is in place and symlinks start working. Does that make >sense? > > >Corinna Sorry, I misstated my summary. I agree, it is not the difference between symlinks in v1.5x versus 1.7x. If I am not mistaken (and there is always a chance of that), generally speaking, I understand that it has to do with the change from the Cygwin 1.5x registry-based mount points to the 1.7x file-based mounts points (/etc/fstab and the (optional) user-specific /etc/fstab.d/$USER). Can I presume it is safe to conclude that in 1.5x the registry-based mount points were available for Cygwin's POSIX path handling earlier and this is why the symlinks worked for /etc/group & /etc/passwd? I now fully understand that symlinks will never work in 1.7x for these "Special files in /etc" and that I will have to find another method to manage these files across multiple clients. I have various methods by which this can be done, none quite as simple as it was in 1.5x when it comes to WinXP. Thank you Corrina, I appreciate your assistance and patience with me! ------------------------------------------------------------------------- >I looked up some information on NTFS junction points. > >From Wikipedia: "Junction points can only link to directories on a >local volume; junction points to remote shares are unsupported." > >You could try Microsoft DFS which *does* support network mounts. > >You could also try fsutil to create a hard link to the /etc/group file >(http://technet.microsoft.com/en-us/library/cc788097%28WS.10%29.aspx). Jason, thank you for taking the time to assist. However, I do not believe this will work in my case. Hard-links, like junction points, will not work over a remote CIFS share either. As for DFS, this is a Server-side implementation and the XP clients would still have to connect to the DFS tree over a remote CIFS share as well. Conceivably, it would work, but the Cygwin directories would then reside over-the-wire and I believe that Cygwin's performance would suffer as a result. Similar to DFS (although a tad simpler), I suppose I could put the entire Cygwin tree on a server (or NAS) and have every client run it from there. I could then also use a customized /etc/fstab to force the 'tmp' mount points to reside on the client's local file system (to ensure tmp files are kept unique to each client). This too would allow me to centrally manage the passwd, group, and other select files. However, I expect it too would take a big performance hit as well. While many apps can run over-the-wire, there simply is no joy when a fast CPU is waiting for data from the network. My goal is to keep the vast majority of Cygwin installed locally. Again, thank you for the suggestion! Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple