RE: All Files and Directories on a Windows Fileserver Share Act Like Character Special Device

["Long, Phillip GOSS" <Phillip dot Long at gossinternational dot com>]

-----Original Message-----
From: Larry Hall (Cygwin)
Sent: Wednesday, October 11, 2006 12:59 AM
To: cygwin mailing list
Subject: Re: All Files and Directories on a Windows Fileserver Share Act
Like Character Special Device

<http://cygwin.com/acronyms/#TOFU>.  Reformatted.

Also, <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.  Don't feed the
spammers.
<snip>
                                    *
                                    *
                                    *
</snip>
>> 
>> 
>> This looks like more of a permissions problem of some kind.  What
does
>> 'getfacl' or 'cacls' have to say about any of these
files/directories?
>> What's the file system here?  Knowing what O/S and sharing protocol
>> would
>> be helpful.  And, in general:
>> 
>>> Problem reports:       http://cygwin.com/problems.html
>> 
>> 'cygcheck' information here is really critical to start.
>> 
 > I do not know _which_ Windows OS the fileservers are running (I only
 > have user access, and no physical access, to them), but it _is_ NTFS
<snip>
                                    *
                                    *
                                    *
</snip>
 > Here is the output of `getfacl' and `cacls' on a directory which does
 > NOT work:
 >       # file: /r/user/LongPhil/Service/qnx/4/logs/unitedlitho
 >       # owner: LongPhil
 >       # group: Domain Users
 >
 >       r:\user\LongPhil\Service\qnx\4\logs\unitedlitho <Account Domain
 > not found>(OI)(CI)F
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^

Bingo!


<snip>
                                    *
                                    *
                                    *
</snip>
Actually, I was looking for 'cygcheck -srv' output but I think we found
the problem without it.  As for the above three packages, yes, you
should
reinstall them if you want to use them.


 > As far as I can tell, nothing changed on the fileservers; IT usually
 > changes _everything_ at once, and usually only in tiny increments.
Our
 > domain users list gets changed fairly regularly, however; could
having
 > an out-of-date /etc/passwd and /etc/group make a difference?


Yes, it does.  Please regenerate them using the '-l' and '-d' switches.
If that's not enough to make the problem go away, you may need to look
at specifying your domain server to the '-d' flag to get things to work.

-- 
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
216 Dalton Rd.                          (508) 893-9889 - FAX
Holliston, MA 01746

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/





Yowie!  Sorry about all the fumbles (email address unclean, no cygcheck
output, TOFU, etc.).  I've never posted on a mailing list using email
before, so all this stuff is new to me; all I've done before is to
search the archives.  As for the email addresses, I have to take them
out by hand, because I'm using the Microstuff Outback email client, and
I haven't found yet how to do that (no regexps for searching help makes
life tough).

I have played around a little bit and have a little more information,
not least of which is the `cygcheck -srv' output.  I have an older
version of Cygwin on a USB disk, and I use this version on occasion on
customer machines.  I rebooted my machine, then logged back on with my
domain account, and used a CMD console to start the older version of
`bash' (I did not use the `cygwin.bat' file from that dist, because I
had modified that version to do a lot of stuff that I didn't want to do
this time).  Running `bash' this way is probably unstable and
crash-prone, but all I did was to map a drive to the questionable share
and try tab-completion, and _that worked_.  I didn't try a cygcheck from
the old dist for fear that the output would be polluted by stuff from
the more recent dist, but I did get a -v output on the older versions of
bash.exe and cygwin1.dll:
	f:/util/cygwin/bin/cygwin1.dll - os=4.0 img=1.0 sys=4.0
	  "cygwin1.dll" v0.0 ts=2003/9/20 16:31
	  C:\WINDOWS\system32\KERNEL32.dll - os=5.1 img=5.1 sys=4.0
	    "KERNEL32.dll" v0.0 ts=2004/8/4 2:14
	    C:\WINDOWS\system32\ntdll.dll - os=5.1 img=5.1 sys=4.10
	      "ntdll.dll" v0.0 ts=2004/8/4 2:15

	f:/util/cygwin/bin/bash.exe - os=4.0 img=1.0 sys=4.0
	Warning: f:/util/cygwin/bin\cygwin1.dll hides
C:\util\cygwin\bin\cygwin1.dll
	  f:/util/cygwin/bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
	    "cygwin1.dll" v0.0 ts=2003/9/20 16:31
	    C:\WINDOWS\system32\KERNEL32.dll - os=5.1 img=5.1 sys=4.0
	      "KERNEL32.dll" v0.0 ts=2004/8/4 2:14
	      C:\WINDOWS\system32\ntdll.dll - os=5.1 img=5.1 sys=4.10
	        "ntdll.dll" v0.0 ts=2004/8/4 2:15
	  C:\WINDOWS\system32\KERNEL32.dll (already done)
	  C:\WINDOWS\system32\USER32.dll - os=5.1 img=5.1 sys=4.0
	    "USER32.dll" v0.0 ts=2005/3/1 20:03
	    C:\WINDOWS\system32\GDI32.dll - os=5.1 img=5.1 sys=4.10
	      "GDI32.dll" v0.0 ts=2005/12/28 19:03
	      C:\WINDOWS\system32\KERNEL32.dll (already done)
	      C:\WINDOWS\system32\ntdll.dll (already done)
	      C:\WINDOWS\system32\USER32.dll (recursive)
	    C:\WINDOWS\system32\KERNEL32.dll (already done)
	    C:\WINDOWS\system32\ntdll.dll (already done)

After rebooting again (Just In Case I had hosed things up running the
older version with the newer version's data in the registry), I tried to
run `mkgroup' and `mkpasswd' like this:
	(mkgroup -l;mkgroup -d) > group 2> g.err
	(mkpasswd -l;mkpasswd -d) > passwd 2> p.err
	(mkpasswd -l;mkpasswd -d goss) < /dev/null > passwd 2>> p.err
The `mkgroup' worked, but I got an `access denied' from `mkpasswd' (this
`access denied' error has been happening for a while, and is one of the
reasons I updated my Cygwin installation; it's also the reason
/etc/passwd is out-of-date).  I had to use my domain account to run
`mkgroup' and `mkpasswd,' of course, since the local administrator
account has no access to domain information (should I make my domain
account part of the administrators group for this?  I didn't think it
would help).  Here is the content of `p.err' (indented for clarity):
	mkpasswd (264): [5] Access is denied.
	mkpasswd (264): [5] Access is denied.
Both times, the content of `passwd' was the same upon exit.  I only got
data for 2792 accounts; the last time I ran this successfully, I got
data for 3056 accounts.  We've had head-count reductions since then, but
not 264 people!

I'm not worried about ACLs too much, unless this is what is tormenting
me on the troublesome fileservers; I have access to a local
administrator account and can change ACLS on my machine as needed.
Since the older version of bash.exe and cygwin1.dll _can_ access the
fileserver as expected, I would guess that something in the way `things'
are handled by underlying DLLs has changed; it has been my pleasant
experience that such Cygwin changes in the past have been for the better
in the long run, so I guess I'll just have to tough it out and re-load
or something.

U can count on a report once I figure it out.  Thank U for the help!

					Thx, Phil the Old Coder
 << File:  cygcheck.srv >>

Attachment: cygcheck.srv
Description: cygcheck.srv

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/