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

[kstmp001 at comcast dot net]

Summary:
--------
- 'id -ng' reports incorrect information when /etc/group is a symlink to 
another valid file containing all of the relevant GROUP information.


First of all, I would like to express my deepest gratitude to all of the 
Cygwin developers, maintainers, and contributors!  I have been an avid 
Cygwin User and Evangelist for over five years.  During this time I have 
found Cygwin to be an extremely powerful environment.

Please keep up the GREAT WORK and THANK YOU for all of your tireless labors!

Unfortunately, I have run into a problem with the latest Cygwin release 
that I alone cannot resolve...

Try as I may, I cannot find any relevant information specific to my 
issue in the FAQ or the newsgroups.  If, however, it has been addressed 
therein already, please accept my sincere apology.


Installation conditions:
--------
- Cygwin 1.75-1
- OS: Windows 7 64-bit, Windows XP 32-bit (separate systems)
- Installed on local (NTFS) file system (C:\cygwin)


Details:
--------
When /etc/group is a symlink to a valid and correctly formatted file 
containing the group information elsewhere on the system (e.g., 
/etc/group -> /etc/_group), 'id -ng' will always return 'mkgroup' as the 
users group.

However, if I remove the /etc/group symlink and rename /etc/_group to 
/etc/group, then 'id -ng' returns the correct user group information 
('None' in this case).

Also, for reference, I have been successfully using a symlink for the 
/etc/group and /etc/passwd files for years in Cygwin 1.5x without issue 
and I would like to continue doing so in 1.7x.  (The reason is to 
provide a more centralized administration method within a Windows Domain 
environment where I only have to maintain a single passwd and group file 
rather than individual files on multiple client systems.)

Therefore, the problem seems to be localized to the use of a symlink in 
Cygwin 1.7x.

I have tried this under the following conditions with no change in the 
result:

- Established the CYGWIN environment variable _prior_ to bash invocation 
as follows:

       CYGWIN=tty

  (confirmed the resulting symlink was the default Cygwin 1.7x 
non-Windows compatible symlink).

  Here is an excerpt of 'strace id -ng':

  37    7191 [main] id 2500 symlink_info::check: 0x0 = NtCreateFile 
(\??\C:\cygwin\etc)
  28    7219 [main] id 2500 symlink_info::check: not a symlink
  23    7242 [main] id 2500 symlink_info::check: 0 = symlink.check 
(C:\cygwin\etc, 0x22B960) (0x1E00A)
  19    7261 [main] id 2500 path_conv::check: 
this->path(C:\cygwin\etc), has_acls(1)
  62    7323 [main] id 2500 etc::test_file_change: 
NtQueryFullAttributesFile (\??\C:\cygwin\etc\group) failed, 0xC0000034
  69    7392 [main] id 2500 etc::test_file_change: 
NtQueryFullAttributesFile (\??\C:\cygwin\etc\group) failed, 0xC0000034
  88    7480 [main] id 2500 pwdgrp::load: \etc\group load failed

- Established the CYGWIN environment variable _prior_ to bash invocation 
as follows:

       CYGWIN=tty winsymlinks

  (confirmed the resulting symlink was a Windows compatible symlink).

  Here is an excerpt of 'strace id -ng':

  35    7073 [main] id 336 symlink_info::check: 0x0 = NtCreateFile 
(\??\C:\cygwin\etc)
  27    7100 [main] id 336 symlink_info::check: not a symlink
  23    7123 [main] id 336 symlink_info::check: 0 = symlink.check 
(C:\cygwin\etc, 0x22B960) (0x1E00A)
  18    7141 [main] id 336 path_conv::check: this->path(C:\cygwin\etc), 
has_acls(1)
  61    7202 [main] id 336 etc::test_file_change: 
NtQueryFullAttributesFile (\??\C:\cygwin\etc\group) failed, 0xC0000034
  68    7270 [main] id 336 etc::test_file_change: 
NtQueryFullAttributesFile (\??\C:\cygwin\etc\group) failed, 0xC0000034
  87    7357 [main] id 336 pwdgrp::load: \etc\group load failed

- Under both conditions, a 'cat /etc/group' displays the same content as 
the target file (e.g., 'cat /etc/_group') indicating the symlink does 
indeed function correctly.  Therefore, this appears to be related to 
'id' (at the least).

Questions:
----------
Is this a bug in Cygwin 1.7.5-1 (within 'id', or some other component)?

Is there a work-around or fix for this issue?

Thank you in advance for your assistance!


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