permission problem after installation under W2K

Randall R Schulz
Tue Apr 9 07:29:00 GMT 2002


Check out my response on the "tar won't restore permissions" thread 
(<>) for notes on setting 
CYGWIN to include ntsec.

CYGWIN must be set before _any_ Cygwin application starts up, because it's 
only during the DLL initialization that "ntsec" in $CYGWIN is effective.

There's another possibility, though it seems like a long shot. Under Unix 
systems, directories are not usable as such without suitable execute bits 
(the kernel won't scan them for any lookup purposes, whether to find a 
target, check for a pre-existing name that is to be created or to traverse 
on the way to an ultimate target deeper in the hierarchy).

It appears by cursory empirical testing, that Cygwin emulates a bit of this 
behavior. A directory (on NTFS with "ntsec" active) without any execute 
bits seems to function normally with one exception: It cannot become the 
current directory:

% # Create and populate "tstDir"
% chmod 666 tstDir
% ls -ld tstDir
drw-rw-rw-    3 RSchulz  None         4096 Apr  9 06:38 tstDir/
% ls -l tstDir
... [ normal ls output ] ...
% cd tstDir
bash: cd: tstDir: Permission denied
% # Same results with sh/ash and tcsh
% mkdir tstDir/newDir
% # Succeeds
% # Other tst of file names beginning with tstDir/ succeed

So... You might want to check and make sure that your "/home" has execute 

Randall Schulz
Mountain View, CA USA

At 04:53 2002-04-09, Ulrich Voss wrote:
> >
> > OK.  Better go to strace and cygcheck -s -r -v output.  Perhaps it's
> > just a missing 'ntsec' setting in your CYGWIN environment variable?
>No it's there ...
>$ cygcheck -s -c -v | grep ntsec
>CYGWIN = `tty ntsec'

Unsubscribe info:
Bug reporting:

More information about the Cygwin mailing list