Re: cygwin 1.7.5, 'id -ng' fails when /etc/group is a symlink

[Ken <kstmp001 at comcast dot net>]

>> 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