RE: not updating unwritable cache ../config.cache

RE: not updating unwritable cache ../config.cache

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4006 bytes --]

Title: RE: not updating unwritable cache ../config.cache





> -----Original Message-----
> From: Kai Henningsen [ mailto:kai@cats.ms ]
> Sent: Thursday, October 07, 1999 10:35 AM
> To: Kai Henningsen; Corinna Vinschen
> Cc: cygwin@sourceware.cygnus.com
> Subject: Re: not updating unwritable cache ../config.cache
> 
> 
> On 6 Oct 99, at 17:03, Corinna Vinschen wrote:
> 
> > Kai Henningsen wrote:
> > > 
> > > On 5 Oct 99, at 20:51, Corinna Vinschen wrote:
> > > 
> > > > And last but not least:
> > > > - Constructive feedback always welcome.
> > > > - Patches are gratefully accepted.
> > > 
> > > Well, here's at least _some_ feedback. Excerpt from building gcc:
> > > 
> > > ----r-xr-x   1 administ Kein       160630 Oct  6 10:15 
> genattrtab.o*
> > > ----r-xr-x   1 administ Kein       253372 Oct  6 10:15 
> genattrtab.exe*
> > > -rw-r--r--   1 kai      Kein       106514 Oct  6 10:15 
> insn-attrtab.c
> > > -rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
> > > ----r-xr-x   1 administ Kein       167908 Oct  6 10:15 
> insn-attrtab.o*
> > > ----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
> > > ----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*
> > 
> > Looks like as if you have edited with ntsec but compiled without it.
> > Would you be so kind to check this out?
> 
> All of these were created from the same "make bootstrap" run. 
> That's what I find so confusing.


Hummm... just a thought:
   genattrtab.o, genattrtab.exe, i386.o, getpwd.o were all created by compiling with some version of gcc installed on your NT box

   insn-attrtab.c is generated by genattrtab.exe, but I think the make rule is like "genattrtab > insn-attrtab.c", so the fact is in fact created by bash (or ash)

   s-attrtab is created by "touch s-attrtab" so is created also by bash/ash (or even directly by make perhaps).


What I'm wondering is that perhaps bash/ash is doing some special things to ensure that the generated files are correctly owned by the effective user, but that other programs may be fooled and attribute rights to the administrator?

> 
> > Another one: Are you sure to have only one cygwin1.dll in $PATH
> > search path?
> 
> Well, I have some cygwin1.dll.something in the same directory as 
> the one to use, but I wouldn't expect those to be used.
> 
> (check environment)
> 
> And yes, it's exported (actually set by the .bat that starts bash).
> 
> Hmm. Maybe someone there clobbers the CYGWIN variable? <find 
> | xargs grep -w CYGWIN> Nope, at least nothing obvious.


Could it be that make do not re-export everything that's passed in the environment? I've header that some versions of gnu-make make some non-usual things in this area.

> 
> Oh! Silly of me. Of _course_. It's the mingw gcc. Obviously, it won't 
> care about ntsec.


Why? mingw gcc is compiled and run in the cygwin environment I think, so go through cygwin1.dll that handles ntsec.


> 
> Regards - Kai Henningsen
> 
> -- 
> http://www.cats.ms
> Spuentrup CTI       Fon: +49 251 322311 0  
> Windbreede 12       Fax: +49 251 322311 99
> D-48157 Münster     Mob: +49 161 3223111
> Germany             GSM: +49 171 7755060
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 


--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
                b.dautrevaux@usa.net
-------------------------------------------- 

RE: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On 7 Oct 99, at 11:52, Bernard Dautrevaux wrote:

> > From: Kai Henningsen [ mailto:kai@cats.ms ]

> > Oh! Silly of me. Of _course_. It's the mingw gcc. Obviously, it won't
> > care about ntsec.
>
> Why? mingw gcc is compiled and run in the cygwin environment I think, so go
> through cygwin1.dll that handles ntsec.

Nope. It's itself a mingw application:

bash-2.02$ cygcheck.exe /gcc-2_95-mingw32/bin/gcc.exe
/gcc-2_95-mingw32/bin/gcc.exe
  E:\WINNT\System32\ADVAPI32.DLL
    E:\WINNT\System32\ntdll.dll
    E:\WINNT\System32\KERNEL32.dll
    E:\WINNT\System32\USER32.dll
      E:\WINNT\System32\GDI32.dll
    E:\WINNT\System32\RPCRT4.dll
  E:\WINNT\System32\crtdll.dll

No cygwin1.dll in there.

Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

On 7 Oct 99, at 11:52, Bernard Dautrevaux wrote:

> > From: Kai Henningsen [ mailto:kai@cats.ms ]

> > Oh! Silly of me. Of _course_. It's the mingw gcc. Obviously, it won't
> > care about ntsec.
>
> Why? mingw gcc is compiled and run in the cygwin environment I think, so go
> through cygwin1.dll that handles ntsec.

Nope. It's itself a mingw application:

bash-2.02$ cygcheck.exe /gcc-2_95-mingw32/bin/gcc.exe
/gcc-2_95-mingw32/bin/gcc.exe
  E:\WINNT\System32\ADVAPI32.DLL
    E:\WINNT\System32\ntdll.dll
    E:\WINNT\System32\KERNEL32.dll
    E:\WINNT\System32\USER32.dll
      E:\WINNT\System32\GDI32.dll
    E:\WINNT\System32\RPCRT4.dll
  E:\WINNT\System32\crtdll.dll

No cygwin1.dll in there.

Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: not updating unwritable cache ../config.cache

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4006 bytes --]

Title: RE: not updating unwritable cache ../config.cache





> -----Original Message-----
> From: Kai Henningsen [ mailto:kai@cats.ms ]
> Sent: Thursday, October 07, 1999 10:35 AM
> To: Kai Henningsen; Corinna Vinschen
> Cc: cygwin@sourceware.cygnus.com
> Subject: Re: not updating unwritable cache ../config.cache
> 
> 
> On 6 Oct 99, at 17:03, Corinna Vinschen wrote:
> 
> > Kai Henningsen wrote:
> > > 
> > > On 5 Oct 99, at 20:51, Corinna Vinschen wrote:
> > > 
> > > > And last but not least:
> > > > - Constructive feedback always welcome.
> > > > - Patches are gratefully accepted.
> > > 
> > > Well, here's at least _some_ feedback. Excerpt from building gcc:
> > > 
> > > ----r-xr-x   1 administ Kein       160630 Oct  6 10:15 
> genattrtab.o*
> > > ----r-xr-x   1 administ Kein       253372 Oct  6 10:15 
> genattrtab.exe*
> > > -rw-r--r--   1 kai      Kein       106514 Oct  6 10:15 
> insn-attrtab.c
> > > -rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
> > > ----r-xr-x   1 administ Kein       167908 Oct  6 10:15 
> insn-attrtab.o*
> > > ----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
> > > ----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*
> > 
> > Looks like as if you have edited with ntsec but compiled without it.
> > Would you be so kind to check this out?
> 
> All of these were created from the same "make bootstrap" run. 
> That's what I find so confusing.


Hummm... just a thought:
   genattrtab.o, genattrtab.exe, i386.o, getpwd.o were all created by compiling with some version of gcc installed on your NT box

   insn-attrtab.c is generated by genattrtab.exe, but I think the make rule is like "genattrtab > insn-attrtab.c", so the fact is in fact created by bash (or ash)

   s-attrtab is created by "touch s-attrtab" so is created also by bash/ash (or even directly by make perhaps).


What I'm wondering is that perhaps bash/ash is doing some special things to ensure that the generated files are correctly owned by the effective user, but that other programs may be fooled and attribute rights to the administrator?

> 
> > Another one: Are you sure to have only one cygwin1.dll in $PATH
> > search path?
> 
> Well, I have some cygwin1.dll.something in the same directory as 
> the one to use, but I wouldn't expect those to be used.
> 
> (check environment)
> 
> And yes, it's exported (actually set by the .bat that starts bash).
> 
> Hmm. Maybe someone there clobbers the CYGWIN variable? <find 
> | xargs grep -w CYGWIN> Nope, at least nothing obvious.


Could it be that make do not re-export everything that's passed in the environment? I've header that some versions of gnu-make make some non-usual things in this area.

> 
> Oh! Silly of me. Of _course_. It's the mingw gcc. Obviously, it won't 
> care about ntsec.


Why? mingw gcc is compiled and run in the cygwin environment I think, so go through cygwin1.dll that handles ntsec.


> 
> Regards - Kai Henningsen
> 
> -- 
> http://www.cats.ms
> Spuentrup CTI       Fon: +49 251 322311 0  
> Windbreede 12       Fax: +49 251 322311 99
> D-48157 Münster     Mob: +49 161 3223111
> Germany             GSM: +49 171 7755060
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 


--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
                b.dautrevaux@usa.net
-------------------------------------------- 

RE: not updating unwritable cache ../config.cache

[John Wiersba]

> -----Original Message-----
> From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> Sent: Friday, March 24, 2000 4:27 PM
> To: John Wiersba; cygwin@sourceware.cygnus.com
> Subject: Re: not updating unwritable cache ../config.cache
>
> You might want to 
> check your umask
> setting and make sure it doesn't mask out write permissions for group 
> and others...

My umask was set to 02.  I changed it to 0 and created a new file, but -w
still fails.

-- John


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: not updating unwritable cache ../config.cache

[John Wiersba]

> -----Original Message-----
> From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> Sent: Friday, March 24, 2000 4:27 PM
> To: John Wiersba; cygwin@sourceware.cygnus.com
> Subject: Re: not updating unwritable cache ../config.cache
> 
> 
> At 04:02 PM 3/24/00, John Wiersba wrote:
> >1)  The following never works for me
> >    [[ -w FILE ]] && echo ok
> >even if the file *is* writable by me.
> 
> 
> This is known.  You won't get the test to work unless the 
> permission you
> are checking is available "across the board".  Corinna has made some 
> changes to address this under NT/NTFS in later snapshots but 
> that won't
> be any solution for 9x platforms AFAIK.  You might want to 
> check your umask
> setting and make sure it doesn't mask out write permissions for group 
> and others...

I saw the "across the board" mentioned in the faq or user guide.  Is there a
work-around?  Perl's cpan command is totally broken because of this.

Is it fixed in one of the later snapshots?  I don't want to be on the
bleeding edge, but I do want to be able to compile the cygwin code on my
machine.  Is there a relatively stable snapshot I should upgrade to?

Thanks,
John


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: not updating unwritable cache ../config.cache

[Larry Hall (RFK Partners, Inc)]

At 06:15 PM 3/24/00, John Wiersba wrote:
> > -----Original Message-----
> > From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> > Sent: Friday, March 24, 2000 4:27 PM
> > To: John Wiersba; cygwin@sourceware.cygnus.com
> > Subject: Re: not updating unwritable cache ../config.cache
> > 
> > 
> > At 04:02 PM 3/24/00, John Wiersba wrote:
> > >1)  The following never works for me
> > >    [[ -w FILE ]] && echo ok
> > >even if the file *is* writable by me.
> > 
> > 
> > This is known.  You won't get the test to work unless the 
> > permission you
> > are checking is available "across the board".  Corinna has made some 
> > changes to address this under NT/NTFS in later snapshots but 
> > that won't
> > be any solution for 9x platforms AFAIK.  You might want to 
> > check your umask
> > setting and make sure it doesn't mask out write permissions for group 
> > and others...
>
>I saw the "across the board" mentioned in the faq or user guide.  Is there a
>work-around?  Perl's cpan command is totally broken because of this.


Options that I know of that exist for NT include:

   - set ntea in you CYGWIN environment variable (actually I'm not sure this
     addresses the test problem).  This has the detriment of creating a file
     EA DATA. SF at the root of FAT drives that grows very quickly and is 
     hard to get rid of (permissions of all files are saved here).  No such
     file is required or used for NTFS.

   - Use a recent snapshot with CYGWIN set to ntsec, following Corinna's 
     instructions exactly.  This works on NTFS drives only.


Have you checked with others on this list with regard to Perl's problem 
here.  I haven't watched that closely but it seems to me I recall others
on this list reporting Perl running well under Cygwin.  I haven't 
investigated Cygwin Perl myself.


>Is it fixed in one of the later snapshots?  I don't want to be on the
>bleeding edge, but I do want to be able to compile the cygwin code on my
>machine.  Is there a relatively stable snapshot I should upgrade to?


Generally speaking, snapshots are for development only.  They don't get 
"saved".  I expect you'd find using ntsec with a recent snapshot would 
resolve the problem but I don't know for sure.  Of course, if you try this,
you will be working with the current stuff, so you will run a risk.  Still,
if you really want to find a solution for this, you may be interested in 
actually looking at the code in the cygwin DLL and trying to see what's
going on, in which case you need current source.;-)  Also, a mitigating 
factor might be that the current thought is that a new net release is 
pending, which means that the "bleeding edge" may be more stable at this
point than it would be otherwise.  You're best bet always is to back up the
version you have before moving forward, in case you decide you need to fall
back.



Larry



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: not updating unwritable cache ../config.cache

[John Wiersba]

> John Wiersba wrote:
> >
> > 2) The id and ls commands work strangely for me:
> >    > id
> >       uid=500(administrator) gid=100(everyone) groups=100(everyone)
> >    > rm -f FILE; touch FILE; ls -l FILE
> >       -rw-r--r--   1 jrw      JRW             0 Mar 24 15:55 FILE
> >    > cd /c
> >    > rm -f FILE; touch FILE; ls -l FILE
> >       -rw-r--r--   1 winnt    Everyone        0 Mar 24 15:57 FILE
> >    > cat /etc/passwd
> >       WinNT::0:513:::
> >       Administrator::500:513:::
> >       Guest::501:513:::
> >       jrw::544:544:::/bin/ksh
> >    > cat /etc/group
> >       Everyone::0:
> >       JRW::513:
> > I've lived with this "feature" for a long time, but maybe 
> > it's related to
> > this problem?
> >
> From: John Fortin [ mailto:fortinj@attglobal.net ]
>
> Could this be the old "I'm part of the Administrator group" 
> so the Administrator
> User owns all files, not me syndrome?
> 
> Create a new user id which does not have Adminstrator 
> Priveledges and try
> building again.

OK, how do I tell which group I'm part of?  The groups command says
"everyone".  I didn't set up my machine (our computer services group did).
I don't think I can set up a new user id.

But notice that files created by me on c: (a FAT drive) are owned by
winnt/everyone whereas files created by me on d; (an NTFS drive) are owned
by jrw/JRW.  

-- John

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

not updating unwritable cache ../config.cache

[John Wiersba]

I've recently reinstalled full.exe and also the 1/15/99 patches (both binary
and source).  Now I'm trying to build the sources.  My build script looks
like:
   #!/bin/ksh
 
   cd /usr/src/TARGET-OBJ
   /usr/src/dev/configure --prefix=/usr/src/TARGET-INSTALL -v 2>&1 |
                       tee /usr/src/configure.log   
   make         2>&1 | tee /usr/src/make.log
   make install 2>&1 | tee /usr/src/install.log

I'm getting a lot of configure errors which look suspicious:
   not updating unwritable cache ../config.cache

Two things which may be related:

1)  The following never works for me
   [[ -w FILE ]] && echo ok
even if the file *is* writable by me.

2) The id and ls commands work strangely for me:
   > id
      uid=500(administrator) gid=100(everyone) groups=100(everyone)
   > rm -f FILE; touch FILE; ls -l FILE
      -rw-r--r--   1 jrw      JRW             0 Mar 24 15:55 FILE
   > cd /c
   > rm -f FILE; touch FILE; ls -l FILE
      -rw-r--r--   1 winnt    Everyone        0 Mar 24 15:57 FILE
   > cat /etc/passwd  
      WinNT::0:513:::
      Administrator::500:513:::
      Guest::501:513:::
      jrw::544:544:::/bin/ksh
   > cat /etc/group
      Everyone::0:
      JRW::513:
I've lived with this "feature" for a long time, but maybe it's related to
this problem?

Thanks,
John Wiersba

----------------------------------------------------------------------------
---
Here's my cygcheck output:

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Fri Mar 24 15:59:57 2000

WinNT Ver 4.0 build 1381 Service Pack 5

Path:	/opt/cygwin/cygwin-b20/H-i586-cygwin32/bin
	/opt/cygwin-old/local/bin
	/jrw/jrw/mdst/sh
	/jrw/binu
	/jrw/binw
	/opt/java/jdk/bin
	/opt/java/jre/1.2/bin
	.

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

CYGWIN = `  notitle tty nostrip_title binmode glob'
HOME = `/jrw'
MAKE_MODE = `UNIX'
PWD = `/usr/src'

!D: = `D:\jrw'
CDPATH = `.:..:/jrw'
COLUMNS = `80'
COMPUTERNAME = `AA-06025'
COMSPEC = `C:\WINNT\system32\cmd.exe'
DIR_BKMK = `/opt/netscape/jrw'
DIR_CYGWIN_INSTALL = `/opt/cygwin/cygwin-b20'
DIR_CYGWIN_SYS = `/usr/i586-cygwin32'
DIR_CYGWIN_USR = `/opt/cygwin/cygwin-b20/H-i586-cygwin32'
DIR_DATA = `/jrw/jrw/mdst/data'
DIR_JRW = `/jrw/jrw'
DIR_JW = `/jrw/jrw/jw'
DIR_LISTS = `/jrw/jrw/mdst/lists'
DIR_MAB = `/jrw/jrw/mdst/mab'
DIR_MABSI = `/hmrdev/mab'
DIR_MDST = `/jrw/jrw/mdst'
DIR_MDST_BKMK = `/jrw/jrw/mdst/bookmark'
DIR_PL = `/jrw/jrw/mdst/pl'
DIR_PL_LIST = `
	/opt/perl/lib
	/opt/perl/site/lib
	/usr/local/lib/perl5/5.00503
	/usr/local/lib/perl5/5.00503/cygwin32
'
DIR_PRT = `/jrw/prt'
DIR_SH = `/jrw/jrw/mdst/sh'
DIR_SQL = `/jrw/jrw/mdst/sql2sql'
HOMEDRIVE = `C:'
HOMEPATH = `\users\default'
HOSTNAME = `aa-06025'
HOSTTYPE = `i586'
INFOPATH = `/usr/info:/usr/local/info'
LANG = `C'
LC_ALL = `C'
LESS = `-iMn'
LINES = `66'
LISTSDIR = `/jrw/jrw/jw'
MACHTYPE = `i586-pc-cygwin32'
MANPATH = `/usr/man:/usr/local/man'
NUMBER_OF_PROCESSORS = `1'
NWUSERNAME = `jrw32982'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSTYPE = `cygwin32'
PATHEXT = `.COM;.EXE;.BAT;.CMD'
PATH_ORIG =
`/opt/ora805/bin:/c/ORANT/bin:/opt/perl/bin:/c/dmi/win32/bin:/opt/mks/mkssi:
/opt/mks/mksnt:/c/winnt/system32:/c/winnt:.:/opt/supmagic/sqlany50/win:/opt/
supmagic/netmap'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 5 Stepping 1, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0501'
PROMPT = `$P$G'
PS1 = `$(prompt $? \w)'
ROOTDIR = `d:/opt/mks'
SHELL = `/bin/bash'
SHLVL = `1'
SQLANY50 = `d:\opt\supmagic\sqlany50\win'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TCLLIBPATH = `/jrw/jrw/mdst/mab/pkg'
TEMP = `C:\TEMP'
TERM = `linux'
TERM_ORIG = `cygwin'
TMP = `C:\TEMP'
TMPDIR = `C:/TEMP'
TZ = `EST5DST'
USERDOMAIN = `MDST-AA1'
USERNAME = `jrw32982'
USERPROFILE = `C:\WINNT\Profiles\jrw32982'
VISUAL = `myvi'
WIN32DMIPATH = `c:\dmi\win32'
WINDIR = `C:\WINNT'
_ = `/bin/cygcheck'

Use `-r' to scan registry

a:\ fd  FAT        1Mb  50% CP    UN           
c:\ hd  FAT     2044Mb  40% CP    UN           
d:\ hd  NTFS    4104Mb  55% CP CS UN PA FC     
e:\ cd           N/A    N/A                    
f:\ net NWFS     900Mb  39% CP                 SYS
h:\ net NWFS   29281Mb  62% CP                 MEDSTAT
j:\ net NTFS   22001Mb  32% CP CS UN PA FC     
m:\ net NWFS   29281Mb  62% CP                 MEDSTAT
n:\ net NWFS   30393Mb  82% CP                 MEDSTATN
o:\ net NWFS   24897Mb  78% CP                 MEDSTAT
r:\ net NTFS    2055Mb   6% CP CS UN PA FC     
s:\ net NWFS   34688Mb  81% CP                 MEDSTATS
t:\ net NWFS   30393Mb  82% CP                 MEDSTATN
x:\ net NWFS     900Mb  39% CP                 SYS
y:\ net NWFS     900Mb  39% CP                 SYS

d:    /        native  text=binary
a:    /a/a     native  text=binary
c:    /c       native  text=binary

Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\bash.exe
Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cat.exe
Not Found: cpp (good!)
Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\find.exe
Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\gcc.exe
Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\gdb.exe
Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\ld.exe
Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\ls.exe
Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\make.exe
Not Found: sh

  371k 1998/12/01 d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygtcl80.dll
- os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=1998/12/1 3:25
    5k 1998/12/01
d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygtclpip80.dll - os=4.0
img=1.0 sys=4.0
   10k 1998/12/01
d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygtclreg80.dll - os=4.0
img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=1998/12/1 3:25
  600k 1998/12/01 d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygtk80.dll -
os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=1998/12/1 3:28
  451k 1999/01/20 d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygwin1.dll -
os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=1999/1/16 0:09
Use -h to see help about each section

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[John Fortin]

John Wiersba wrote:

> I've recently reinstalled full.exe and also the 1/15/99 patches (both binary
> and source).  Now I'm trying to build the sources.  My build script looks
> like:
>    #!/bin/ksh
>
>    cd /usr/src/TARGET-OBJ
>    /usr/src/dev/configure --prefix=/usr/src/TARGET-INSTALL -v 2>&1 |
>                        tee /usr/src/configure.log
>    make         2>&1 | tee /usr/src/make.log
>    make install 2>&1 | tee /usr/src/install.log
>
> I'm getting a lot of configure errors which look suspicious:
>    not updating unwritable cache ../config.cache
>
> Two things which may be related:
>
> 1)  The following never works for me
>    [[ -w FILE ]] && echo ok
> even if the file *is* writable by me.
>
> 2) The id and ls commands work strangely for me:
>    > id
>       uid=500(administrator) gid=100(everyone) groups=100(everyone)
>    > rm -f FILE; touch FILE; ls -l FILE
>       -rw-r--r--   1 jrw      JRW             0 Mar 24 15:55 FILE
>    > cd /c
>    > rm -f FILE; touch FILE; ls -l FILE
>       -rw-r--r--   1 winnt    Everyone        0 Mar 24 15:57 FILE
>    > cat /etc/passwd
>       WinNT::0:513:::
>       Administrator::500:513:::
>       Guest::501:513:::
>       jrw::544:544:::/bin/ksh
>    > cat /etc/group
>       Everyone::0:
>       JRW::513:
> I've lived with this "feature" for a long time, but maybe it's related to
> this problem?
>
> Thanks,
> John Wiersba
>
> ----------------------------------------------------------------------------
> ---
> Here's my cygcheck output:
>
> Cygnus Win95/NT Configuration Diagnostics
> Current System Time: Fri Mar 24 15:59:57 2000
>
> WinNT Ver 4.0 build 1381 Service Pack 5
>
> Path:   /opt/cygwin/cygwin-b20/H-i586-cygwin32/bin
>         /opt/cygwin-old/local/bin
>         /jrw/jrw/mdst/sh
>         /jrw/binu
>         /jrw/binw
>         /opt/java/jdk/bin
>         /opt/java/jre/1.2/bin
>         .
>
> SysDir: C:\WINNT\System32
> WinDir: C:\WINNT
>
> CYGWIN = `  notitle tty nostrip_title binmode glob'
> HOME = `/jrw'
> MAKE_MODE = `UNIX'
> PWD = `/usr/src'
>
> !D: = `D:\jrw'
> CDPATH = `.:..:/jrw'
> COLUMNS = `80'
> COMPUTERNAME = `AA-06025'
> COMSPEC = `C:\WINNT\system32\cmd.exe'
> DIR_BKMK = `/opt/netscape/jrw'
> DIR_CYGWIN_INSTALL = `/opt/cygwin/cygwin-b20'
> DIR_CYGWIN_SYS = `/usr/i586-cygwin32'
> DIR_CYGWIN_USR = `/opt/cygwin/cygwin-b20/H-i586-cygwin32'
> DIR_DATA = `/jrw/jrw/mdst/data'
> DIR_JRW = `/jrw/jrw'
> DIR_JW = `/jrw/jrw/jw'
> DIR_LISTS = `/jrw/jrw/mdst/lists'
> DIR_MAB = `/jrw/jrw/mdst/mab'
> DIR_MABSI = `/hmrdev/mab'
> DIR_MDST = `/jrw/jrw/mdst'
> DIR_MDST_BKMK = `/jrw/jrw/mdst/bookmark'
> DIR_PL = `/jrw/jrw/mdst/pl'
> DIR_PL_LIST = `
>         /opt/perl/lib
>         /opt/perl/site/lib
>         /usr/local/lib/perl5/5.00503
>         /usr/local/lib/perl5/5.00503/cygwin32
> '
> DIR_PRT = `/jrw/prt'
> DIR_SH = `/jrw/jrw/mdst/sh'
> DIR_SQL = `/jrw/jrw/mdst/sql2sql'
> HOMEDRIVE = `C:'
> HOMEPATH = `\users\default'
> HOSTNAME = `aa-06025'
> HOSTTYPE = `i586'
> INFOPATH = `/usr/info:/usr/local/info'
> LANG = `C'
> LC_ALL = `C'
> LESS = `-iMn'
> LINES = `66'
> LISTSDIR = `/jrw/jrw/jw'
> MACHTYPE = `i586-pc-cygwin32'
> MANPATH = `/usr/man:/usr/local/man'
> NUMBER_OF_PROCESSORS = `1'
> NWUSERNAME = `jrw32982'
> OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
> OS = `Windows_NT'
> OSTYPE = `cygwin32'
> PATHEXT = `.COM;.EXE;.BAT;.CMD'
> PATH_ORIG =
> `/opt/ora805/bin:/c/ORANT/bin:/opt/perl/bin:/c/dmi/win32/bin:/opt/mks/mkssi:
> /opt/mks/mksnt:/c/winnt/system32:/c/winnt:.:/opt/supmagic/sqlany50/win:/opt/
> supmagic/netmap'
> PROCESSOR_ARCHITECTURE = `x86'
> PROCESSOR_IDENTIFIER = `x86 Family 6 Model 5 Stepping 1, GenuineIntel'
> PROCESSOR_LEVEL = `6'
> PROCESSOR_REVISION = `0501'
> PROMPT = `$P$G'
> PS1 = `$(prompt $? \w)'
> ROOTDIR = `d:/opt/mks'
> SHELL = `/bin/bash'
> SHLVL = `1'
> SQLANY50 = `d:\opt\supmagic\sqlany50\win'
> SYSTEMDRIVE = `C:'
> SYSTEMROOT = `C:\WINNT'
> TCLLIBPATH = `/jrw/jrw/mdst/mab/pkg'
> TEMP = `C:\TEMP'
> TERM = `linux'
> TERM_ORIG = `cygwin'
> TMP = `C:\TEMP'
> TMPDIR = `C:/TEMP'
> TZ = `EST5DST'
> USERDOMAIN = `MDST-AA1'
> USERNAME = `jrw32982'
> USERPROFILE = `C:\WINNT\Profiles\jrw32982'
> VISUAL = `myvi'
> WIN32DMIPATH = `c:\dmi\win32'
> WINDIR = `C:\WINNT'
> _ = `/bin/cygcheck'
>
> Use `-r' to scan registry
>
> a:\ fd  FAT        1Mb  50% CP    UN
> c:\ hd  FAT     2044Mb  40% CP    UN
> d:\ hd  NTFS    4104Mb  55% CP CS UN PA FC
> e:\ cd           N/A    N/A
> f:\ net NWFS     900Mb  39% CP                 SYS
> h:\ net NWFS   29281Mb  62% CP                 MEDSTAT
> j:\ net NTFS   22001Mb  32% CP CS UN PA FC
> m:\ net NWFS   29281Mb  62% CP                 MEDSTAT
> n:\ net NWFS   30393Mb  82% CP                 MEDSTATN
> o:\ net NWFS   24897Mb  78% CP                 MEDSTAT
> r:\ net NTFS    2055Mb   6% CP CS UN PA FC
> s:\ net NWFS   34688Mb  81% CP                 MEDSTATS
> t:\ net NWFS   30393Mb  82% CP                 MEDSTATN
> x:\ net NWFS     900Mb  39% CP                 SYS
> y:\ net NWFS     900Mb  39% CP                 SYS
>
> d:    /        native  text=binary
> a:    /a/a     native  text=binary
> c:    /c       native  text=binary
>
> Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\bash.exe
> Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cat.exe
> Not Found: cpp (good!)
> Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\find.exe
> Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\gcc.exe
> Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\gdb.exe
> Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\ld.exe
> Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\ls.exe
> Found: d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\make.exe
> Not Found: sh
>
>   371k 1998/12/01 d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygtcl80.dll
> - os=4.0 img=1.0 sys=4.0
>                   "cygtcl80.dll" v0.0 ts=1998/12/1 3:25
>     5k 1998/12/01
> d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygtclpip80.dll - os=4.0
> img=1.0 sys=4.0
>    10k 1998/12/01
> d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygtclreg80.dll - os=4.0
> img=1.0 sys=4.0
>                   "cygtclreg80.dll" v0.0 ts=1998/12/1 3:25
>   600k 1998/12/01 d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygtk80.dll -
> os=4.0 img=1.0 sys=4.0
>                   "cygtk80.dll" v0.0 ts=1998/12/1 3:28
>   451k 1999/01/20 d:\opt\cygwin\cygwin-b20\H-i586-cygwin32\bin\cygwin1.dll -
> os=4.0 img=1.0 sys=4.0
>                   "cygwin1.dll" v0.0 ts=1999/1/16 0:09
> Use -h to see help about each section
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Could this be the old "I'm part of the Administrator group" so the Administrator
User owns all files, not me syndrome?

Create a new user id which does not have Adminstrator Priveledges and try
building again.

John




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Larry Hall (RFK Partners, Inc)]

At 04:02 PM 3/24/00, John Wiersba wrote:
>1)  The following never works for me
>    [[ -w FILE ]] && echo ok
>even if the file *is* writable by me.


This is known.  You won't get the test to work unless the permission you
are checking is available "across the board".  Corinna has made some 
changes to address this under NT/NTFS in later snapshots but that won't
be any solution for 9x platforms AFAIK.  You might want to check your umask
setting and make sure it doesn't mask out write permissions for group 
and others...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX
                                        (508) 560-1285 - cell phone



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: not updating unwritable cache ../config.cache

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

Title: RE: not updating unwritable cache ../config.cache





> -----Original Message-----
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> Sent: Thursday, October 07, 1999 1:43 PM
> To: Bernard Dautrevaux
> Cc: cygwin@sourceware.cygnus.com
> Subject: RE: not updating unwritable cache ../config.cache
> 
> 
> --- Bernard Dautrevaux <DAUTREVAUX@microprocess.com> wrote:
> -8<-
> > 
> > Why? mingw gcc is compiled and run in the cygwin 
> environment I think, so go
> > through cygwin1.dll that handles ntsec.
> > 
> -8<-
> 
> Mingw32 gcc and binutils _DO_NOT_ use the cygwin1.dll.  That 
> is the reason it
> exists.  Instead it uses the runtime from M$.  So, Kai is 
> correct that Mingw32
> doesn't care about ntsec as far as the it's implementation 
> within cygwin1.dll.
> 


I do know that the code _generated_ by mingw32 do not use cygwin1.dll; that's effectively the reason why it exists :-)


But I think I've read that the "native" mingw32 toolset was in fact running under cygwin and using cygwin1.dll... but perhaps this is only true for the mingw32 cygwin-add-on, not for the independently distributed one. 

Forgive me if I'm not really sure, but for now quite a long time I'm using always mingw32 for all my NT development, but I'm using a cross-compiler running on UNIX (usually Linux, but I've also built the cross-toolset on other flavors of UNIX, like Solaris, where it runs fine).

Regards,


                Bernard


--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
                b.dautrevaux@usa.net
-------------------------------------------- 

RE: not updating unwritable cache ../config.cache

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1879 bytes --]

Title: RE: not updating unwritable cache ../config.cache





> -----Original Message-----
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> Sent: Thursday, October 07, 1999 1:43 PM
> To: Bernard Dautrevaux
> Cc: cygwin@sourceware.cygnus.com
> Subject: RE: not updating unwritable cache ../config.cache
> 
> 
> --- Bernard Dautrevaux <DAUTREVAUX@microprocess.com> wrote:
> -8<-
> > 
> > Why? mingw gcc is compiled and run in the cygwin 
> environment I think, so go
> > through cygwin1.dll that handles ntsec.
> > 
> -8<-
> 
> Mingw32 gcc and binutils _DO_NOT_ use the cygwin1.dll.  That 
> is the reason it
> exists.  Instead it uses the runtime from M$.  So, Kai is 
> correct that Mingw32
> doesn't care about ntsec as far as the it's implementation 
> within cygwin1.dll.
> 


I do know that the code _generated_ by mingw32 do not use cygwin1.dll; that's effectively the reason why it exists :-)


But I think I've read that the "native" mingw32 toolset was in fact running under cygwin and using cygwin1.dll... but perhaps this is only true for the mingw32 cygwin-add-on, not for the independently distributed one. 

Forgive me if I'm not really sure, but for now quite a long time I'm using always mingw32 for all my NT development, but I'm using a cross-compiler running on UNIX (usually Linux, but I've also built the cross-toolset on other flavors of UNIX, like Solaris, where it runs fine).

Regards,


                Bernard


--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
                b.dautrevaux@usa.net
-------------------------------------------- 

RE: not updating unwritable cache ../config.cache

[Earnie Boyd]

--- Bernard Dautrevaux <DAUTREVAUX@microprocess.com> wrote:
-8<-
> 
> Why? mingw gcc is compiled and run in the cygwin environment I think, so go
> through cygwin1.dll that handles ntsec.
> 
-8<-

Mingw32 gcc and binutils _DO_NOT_ use the cygwin1.dll.  That is the reason it
exists.  Instead it uses the runtime from M$.  So, Kai is correct that Mingw32
doesn't care about ntsec as far as the it's implementation within cygwin1.dll.

=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >

(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: not updating unwritable cache ../config.cache

[Earnie Boyd]

--- Bernard Dautrevaux <DAUTREVAUX@microprocess.com> wrote:
-8<-
> 
> Why? mingw gcc is compiled and run in the cygwin environment I think, so go
> through cygwin1.dll that handles ntsec.
> 
-8<-

Mingw32 gcc and binutils _DO_NOT_ use the cygwin1.dll.  That is the reason it
exists.  Instead it uses the runtime from M$.  So, Kai is correct that Mingw32
doesn't care about ntsec as far as the it's implementation within cygwin1.dll.

=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >

(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Charles S. Wilson]

> 
> bash-2.02$ ls -la test
> -rw-r--r--   1 544      Kein            0 Oct  5 09:57 test
> bash-2.02$ echo > test
> bash-2.02$ ls -la test
> -rw-r--r--   1 544      Kein            2 Oct  6 09:08 test
> bash-2.02$ echo >> test
> bash-2.02$ ls -la test
> -rw-r--r--   1 544      Kein            4 Oct  6 09:08 test
> bash-2.02$
> 
> Umm, nope.
> 

group #544 is Administrators
so test is owned by Administrators, group "Kein" ("None"? -- do an ls
-lan. This should show  "-rw-r--r--   1 544     513    .....". Group
#513 is "None" in english.) I believe you have discovered a *different*
problem, which is a bug. Echo doesn't seem to check permissions. If you
do a 

if [ -w test ]; then echo writable; else echo non-writable; fi

you should see the results I described.

> >--- there is no single user whose UID is equal to the GID of
> > the Administrators group. There are two ways to work around this NTism
> > (maybe 3?)
> >
> > This is true for the "Administrator" account as well. UID(Administrator)
> > != GID(Administrators) --- note the final 's' on the group name.
> >
> > 1) change umask so that files are created as -rw-rw-r--. Then all users
> > in the Administrators group can r/w the files they create.
> 
> bash-2.02$ umask
> 000
> bash-2.02$
> 
> Hmmm ...
> 

Oh yeah. Sorry. I forgot that the only thing umask does is *remove*
privileges from created files. If the default access mode is -rw-rw-rw-
and you have a umask of 022, then the file will be created with
group-write and all-write access disabled (-rw-r--r--). By setting umask
to 000, you have shown that the default access mode is -rw-r--r--. You
can't use umask to *add* priveleges (such as group-write). There is a
way to do that, but I don't remember what it was...

> > 2) Don't do things as a member of the Administrators group member. Use a
> > normal user account.
> 
> It's the only one I have.

However, if you have administrator priveleges, then you can certainly
create a normal user account. If you *choose* not to do this, that is
your right and your decision. 

> 
> > 3) ntsec ???
> 
> Well?

I don't know enough about ntsec and the latest snapshots to offer useful
advice; Corinna has explained ntsec earlier in this thread.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

On 6 Oct 99, at 11:51, Charles S. Wilson wrote:

> #513 is "None" in english.) I believe you have discovered a *different*
> problem, which is a bug. Echo doesn't seem to check permissions. If you
> do a

Huh?! Echo (rather, bash) _should not_ check permissions. It
should just try to do what it's told to do.

> if [ -w test ]; then echo writable; else echo non-writable; fi
>
> you should see the results I described.

Well yes, and _that_ is the bug.

Under Unix, this is typically done with supplementary groups (from our server:
$ id
uid=1000(kai) gid=1000(kai) groups=1000(kai),20(dialout),33(www-data),50(staff),102(entwicklung),104(everyone)
$
), but of course that isn't _exactly_ what NT does.

The usual solution (even under Unix) is that most accesses just try
and see if the kernel lets them through, and stuff like test uses
access() which maps, again, to a system call so the kernel
determines if the access in question is possible. The stat() results
should only ever be used for security outside the kernel in
extraordinary circumstances.

Of course, cygwin _could_ define parts of newlib as kernel, but in
this particular case, that seems pointless. Security that only works
for programs compiled with cygwin seems futile.

On the other hand, I don't know what the Win32 analog to access()
would be. Maybe the only choice is to actually try to open the file
(except for the existence test, of course).

> > > 2) Don't do things as a member of the Administrators group member. Use a
> > > normal user account.
> >
> > It's the only one I have.
>
> However, if you have administrator priveleges, then you can certainly
> create a normal user account. If you *choose* not to do this, that is
> your right and your decision.

If I create a different account, then NT will keep me from important
applications, I'll have trouble getting at my mail, I'll have trouble
mapping network drives, ...

Not really unsolvable, but a _huge_ amount of work.


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

On 6 Oct 99, at 11:51, Charles S. Wilson wrote:

> #513 is "None" in english.) I believe you have discovered a *different*
> problem, which is a bug. Echo doesn't seem to check permissions. If you
> do a

Huh?! Echo (rather, bash) _should not_ check permissions. It
should just try to do what it's told to do.

> if [ -w test ]; then echo writable; else echo non-writable; fi
>
> you should see the results I described.

Well yes, and _that_ is the bug.

Under Unix, this is typically done with supplementary groups (from our server:
$ id
uid=1000(kai) gid=1000(kai) groups=1000(kai),20(dialout),33(www-data),50(staff),102(entwicklung),104(everyone)
$
), but of course that isn't _exactly_ what NT does.

The usual solution (even under Unix) is that most accesses just try
and see if the kernel lets them through, and stuff like test uses
access() which maps, again, to a system call so the kernel
determines if the access in question is possible. The stat() results
should only ever be used for security outside the kernel in
extraordinary circumstances.

Of course, cygwin _could_ define parts of newlib as kernel, but in
this particular case, that seems pointless. Security that only works
for programs compiled with cygwin seems futile.

On the other hand, I don't know what the Win32 analog to access()
would be. Maybe the only choice is to actually try to open the file
(except for the existence test, of course).

> > > 2) Don't do things as a member of the Administrators group member. Use a
> > > normal user account.
> >
> > It's the only one I have.
>
> However, if you have administrator priveleges, then you can certainly
> create a normal user account. If you *choose* not to do this, that is
> your right and your decision.

If I create a different account, then NT will keep me from important
applications, I'll have trouble getting at my mail, I'll have trouble
mapping network drives, ...

Not really unsolvable, but a _huge_ amount of work.


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Charles S. Wilson]

> 
> bash-2.02$ ls -la test
> -rw-r--r--   1 544      Kein            0 Oct  5 09:57 test
> bash-2.02$ echo > test
> bash-2.02$ ls -la test
> -rw-r--r--   1 544      Kein            2 Oct  6 09:08 test
> bash-2.02$ echo >> test
> bash-2.02$ ls -la test
> -rw-r--r--   1 544      Kein            4 Oct  6 09:08 test
> bash-2.02$
> 
> Umm, nope.
> 

group #544 is Administrators
so test is owned by Administrators, group "Kein" ("None"? -- do an ls
-lan. This should show  "-rw-r--r--   1 544     513    .....". Group
#513 is "None" in english.) I believe you have discovered a *different*
problem, which is a bug. Echo doesn't seem to check permissions. If you
do a 

if [ -w test ]; then echo writable; else echo non-writable; fi

you should see the results I described.

> >--- there is no single user whose UID is equal to the GID of
> > the Administrators group. There are two ways to work around this NTism
> > (maybe 3?)
> >
> > This is true for the "Administrator" account as well. UID(Administrator)
> > != GID(Administrators) --- note the final 's' on the group name.
> >
> > 1) change umask so that files are created as -rw-rw-r--. Then all users
> > in the Administrators group can r/w the files they create.
> 
> bash-2.02$ umask
> 000
> bash-2.02$
> 
> Hmmm ...
> 

Oh yeah. Sorry. I forgot that the only thing umask does is *remove*
privileges from created files. If the default access mode is -rw-rw-rw-
and you have a umask of 022, then the file will be created with
group-write and all-write access disabled (-rw-r--r--). By setting umask
to 000, you have shown that the default access mode is -rw-r--r--. You
can't use umask to *add* priveleges (such as group-write). There is a
way to do that, but I don't remember what it was...

> > 2) Don't do things as a member of the Administrators group member. Use a
> > normal user account.
> 
> It's the only one I have.

However, if you have administrator priveleges, then you can certainly
create a normal user account. If you *choose* not to do this, that is
your right and your decision. 

> 
> > 3) ntsec ???
> 
> Well?

I don't know enough about ntsec and the latest snapshots to offer useful
advice; Corinna has explained ntsec earlier in this thread.

--Chuck

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Earnie Boyd]

--- Kai Henningsen <kai@cats.ms> wrote:
> On 5 Oct 99, at 5:29, Glenn Spell wrote:
> 
> > On 5 Oct 1999 around 10:59AM (+0200) Kai Henningsen wrote:
> >
> > > On 5 Oct 99, at 10:15, I wrote:
> > >
> > > > I'm seeing this every time I ./configure something. Anybody know
> > > > what is going on?
> > > >
> > > > Sure doesn't _look_ unwritable. Besides, the very same script
> > > > just created it.
> >
> > It's unwritable by anyone other the owner of the file.
> >
> > > Well, it's "test -w" failing. Obviously because of this:
> > > bash-2.02$ id
> > > uid=1000(kai) gid=513(Kein) groups=513(Kein)
> >       ^^^^
> > > bash-2.02$ chmod a+w test
> >

This is a reported and known bug.  Have you tried it with a snapshot?

> > If you're using a recent snapshot, setting "ntsec" in your CYGWIN
> > variable may cause chmod to work correctly. (I say "may" because I
> > really don't know. I don't run NT.) Historically, chmod returns
> > without error on Cygwin but does nothing.
> >

"ntsec" is definitely the wrong option here.  If you want extended attributes
you can turn this on with "ntea".  CAUTION: doing this on a FAT partition will
cause file in the root of all FAT drives accessed by cygwin to grow a large
file that isn't easily delete-able to be created.  Also, all diskettes will
have the "EA DATA" system file as well.

> > > bash-2.02$ ls -la test
> > > -rw-r--r-- 1 544 Kein 0 Oct 5 09:57 test
> >                ^^^
> > You (UID 1000) don't own the file, UID 544 (administrator) owns
> > it. (I guess you already knew that. :-)
> 
> What I don't understand is how this happens. After all, I created the
> file. And I _can_ write to the file. Something is very wrong here.
> 
> > You need to login as administrator

Kai is already in the administrators group which makes him an administrator. 
This also makes all files created owned by the adminstrator.  The real problem
is the test -w bug.

I suggest trying a more recent snapshot.  Caveat: save any files that you
replace as you may need to backout.


=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >

(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Corinna Vinschen]

Earnie Boyd wrote:
> [...]
> "ntsec" is definitely the wrong option here.  If you want extended attributes
> you can turn this on with "ntea".  CAUTION: doing this on a FAT partition will
> cause file in the root of all FAT drives accessed by cygwin to grow a large
> file that isn't easily delete-able to be created.  Also, all diskettes will
> have the "EA DATA" system file as well.

'ntsec' is definitely not the wrong option. 'ntsec' is the better
choice if you are using NTFS filesystems. 'ntea' is a hack that uses
a cryptic WinNT method for creating and reading hidden file contents.
It's hard to erase them later if you need to do so. Moreover the
method to save this so called 'extended attributes' on FAT partitions
is an impertinence.

If you are working with FAT, unfortunately, try a newer snapshot of
cygwin1.dll. The simulated file ownership should do it for you.
And don't use an account, that is member of the administrators group.
In this case the file owner and the user are diverging.

Regards,
Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On 5 Oct 99, at 14:40, Corinna Vinschen wrote:

> 'ntsec' is definitely not the wrong option. 'ntsec' is the better
> choice if you are using NTFS filesystems. 'ntea' is a hack that uses

What do I need for it, then?

> If you are working with FAT, unfortunately, try a newer snapshot of

Nope, all NTFS.

> And don't use an account, that is member of the administrators group.

Not really an option.

> In this case the file owner and the user are diverging.

Huh. NT bug?


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Corinna Vinschen]

Kai Henningsen wrote:
> 
> On 5 Oct 99, at 14:40, Corinna Vinschen wrote:
> 
> > 'ntsec' is definitely not the wrong option. 'ntsec' is the better
> > choice if you are using NTFS filesystems. 'ntea' is a hack that uses
> 
> What do I need for it, then?

Use mkpasswd and mkgroup to create /etc/passwd and /etc/group files.
In the current snapshots, the following rules are important:

- Dont use user and/or group names that are different from the
  NT account names.
  Ever:  administrators::544:
  Never: admins::544:
- Typically, group 513 is your primary group. This is `None' outside
  and `Domain Users' inside of NT domains.
  The primary group membership isn't important for `ntsec', so you
  may change your group entry in /etc/passwd to, e.g., administrators
  group:

	kai::1000:544:Kai Henningsen:/home/kai:/bin/sh

- Use `umask' command in your profile, e.g.: `umask 022'.

Try a `touch foo' and `ls -l foo'. Without `ntsec' you'll get:

  -rw-r--r-- 1 administ none        0 Oct 5 20:00 foo

With `ntsec':

  -rw-r--r-- 1 kai      administ    0 Oct 5 20:00 foo

> > And don't use an account, that is member of the administrators group.
> 
> Not really an option.

When you try `ntsec' you will see that this problem is gone.
Maybe, you get other ones... but I'm working hard in making
`ntsec' better.

And last but not least:
- Constructive feedback always welcome.
- Patches are gratefully accepted.

> 
> > In this case the file owner and the user are diverging.
> 
> Huh. NT bug?

No, NT `feature' ;-}
If a user is member of the administrators group, the administrators
group will be the owner of _every_ object that is created by him/her
(including files, processes, semaphores,...)
_if_ _not_ _explicitly_ _changed_! This job is done by `ntsec'.

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On 5 Oct 99, at 20:51, Corinna Vinschen wrote:

> Use mkpasswd and mkgroup to create /etc/passwd and /etc/group files.
> In the current snapshots, the following rules are important:
>
> - Dont use user and/or group names that are different from the
>   NT account names.
>   Ever:  administrators::544:
>   Never: admins::544:
> - Typically, group 513 is your primary group. This is `None' outside
>   and `Domain Users' inside of NT domains.
>   The primary group membership isn't important for `ntsec', so you
>   may change your group entry in /etc/passwd to, e.g., administrators
>   group:
>
> 	kai::1000:544:Kai Henningsen:/home/kai:/bin/sh

Supplementary groups don't work, right? (Just making sure I
understand what's going on.)

Anyway, given that NT doesn't quite seem to see a difference
between user and group ids (Novell is similar, incidentally), I
decided

	mkdir /etc
	cd /etc
	( mkpasswd -l -g ; mkgroup -l ) | sort -n -t: +2 > common
	ln common passwd
	ln common group

was the way to go here.

Using the 19990929 cygwin1.dll, this seems to work now. Thanks!

One more question: I see directories getting the other t bit set.
What does this mean?

> When you try `ntsec' you will see that this problem is gone.
> Maybe, you get other ones... but I'm working hard in making
> `ntsec' better.

Thanks again!


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Corinna Vinschen]

Kai Henningsen wrote:
> [...]
> Supplementary groups don't work, right? (Just making sure I
> understand what's going on.)

You can only have one primary group which is the group that
is your default group for file creation.
`newgrp' isn't supported yet but maybe later (shouldn't be too
complex).

> Anyway, given that NT doesn't quite seem to see a difference
> between user and group ids (Novell is similar, incidentally), I
> decided
> 
>         mkdir /etc
>         cd /etc
>         ( mkpasswd -l -g ; mkgroup -l ) | sort -n -t: +2 > common
>         ln common passwd
>         ln common group

This isn't completely right! A group may be used as owner of an
object but a user must not be used as "group" in a security
descriptor. So users shouldn't reside in the group file though
they wouldn't disturb there.

> Using the 19990929 cygwin1.dll, this seems to work now. Thanks!
> 
> One more question: I see directories getting the other t bit set.
> What does this mean?

Grin! The 't' bit is the sticky bit that is used in a linux style
manner. It only make sense for directories and it's typically set
on /tmp (rwxrwxrwt) and has the effect, that anybody may read and
write in /tmp but he/she can't erase files of other users.

Unfortunately, the sticky bit is set in ntsec by mistake. I had
corrected this a few days ago and the _next_ snapshot after yours
(19991001) behaves correctly.

Regards,
Corinna



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Corinna Vinschen]

Kai Henningsen wrote:
> [...]
> Supplementary groups don't work, right? (Just making sure I
> understand what's going on.)

You can only have one primary group which is the group that
is your default group for file creation.
`newgrp' isn't supported yet but maybe later (shouldn't be too
complex).

> Anyway, given that NT doesn't quite seem to see a difference
> between user and group ids (Novell is similar, incidentally), I
> decided
> 
>         mkdir /etc
>         cd /etc
>         ( mkpasswd -l -g ; mkgroup -l ) | sort -n -t: +2 > common
>         ln common passwd
>         ln common group

This isn't completely right! A group may be used as owner of an
object but a user must not be used as "group" in a security
descriptor. So users shouldn't reside in the group file though
they wouldn't disturb there.

> Using the 19990929 cygwin1.dll, this seems to work now. Thanks!
> 
> One more question: I see directories getting the other t bit set.
> What does this mean?

Grin! The 't' bit is the sticky bit that is used in a linux style
manner. It only make sense for directories and it's typically set
on /tmp (rwxrwxrwt) and has the effect, that anybody may read and
write in /tmp but he/she can't erase files of other users.

Unfortunately, the sticky bit is set in ntsec by mistake. I had
corrected this a few days ago and the _next_ snapshot after yours
(19991001) behaves correctly.

Regards,
Corinna



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On 5 Oct 99, at 20:51, Corinna Vinschen wrote:

> Use mkpasswd and mkgroup to create /etc/passwd and /etc/group files.
> In the current snapshots, the following rules are important:
>
> - Dont use user and/or group names that are different from the
>   NT account names.
>   Ever:  administrators::544:
>   Never: admins::544:
> - Typically, group 513 is your primary group. This is `None' outside
>   and `Domain Users' inside of NT domains.
>   The primary group membership isn't important for `ntsec', so you
>   may change your group entry in /etc/passwd to, e.g., administrators
>   group:
>
> 	kai::1000:544:Kai Henningsen:/home/kai:/bin/sh

Supplementary groups don't work, right? (Just making sure I
understand what's going on.)

Anyway, given that NT doesn't quite seem to see a difference
between user and group ids (Novell is similar, incidentally), I
decided

	mkdir /etc
	cd /etc
	( mkpasswd -l -g ; mkgroup -l ) | sort -n -t: +2 > common
	ln common passwd
	ln common group

was the way to go here.

Using the 19990929 cygwin1.dll, this seems to work now. Thanks!

One more question: I see directories getting the other t bit set.
What does this mean?

> When you try `ntsec' you will see that this problem is gone.
> Maybe, you get other ones... but I'm working hard in making
> `ntsec' better.

Thanks again!


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On 5 Oct 99, at 20:51, Corinna Vinschen wrote:

> And last but not least:
> - Constructive feedback always welcome.
> - Patches are gratefully accepted.

Well, here's at least _some_ feedback. Excerpt from building gcc:

----r-xr-x   1 administ Kein       160630 Oct  6 10:15 genattrtab.o*
----r-xr-x   1 administ Kein       253372 Oct  6 10:15 genattrtab.exe*
-rw-r--r--   1 kai      Kein       106514 Oct  6 10:15 insn-attrtab.c
-rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
----r-xr-x   1 administ Kein       167908 Oct  6 10:15 insn-attrtab.o*
----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*

Strange.


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Corinna Vinschen]

Kai Henningsen wrote:
> 
> On 5 Oct 99, at 20:51, Corinna Vinschen wrote:
> 
> > And last but not least:
> > - Constructive feedback always welcome.
> > - Patches are gratefully accepted.
> 
> Well, here's at least _some_ feedback. Excerpt from building gcc:
> 
> ----r-xr-x   1 administ Kein       160630 Oct  6 10:15 genattrtab.o*
> ----r-xr-x   1 administ Kein       253372 Oct  6 10:15 genattrtab.exe*
> -rw-r--r--   1 kai      Kein       106514 Oct  6 10:15 insn-attrtab.c
> -rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
> ----r-xr-x   1 administ Kein       167908 Oct  6 10:15 insn-attrtab.o*
> ----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
> ----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*

Looks like as if you have edited with ntsec but compiled without it.
Would you be so kind to check this out?
Another one: Are you sure to have only one cygwin1.dll in $PATH
search path?

> Strange.

Yep. But this should have a simple solution. I'm using ntsec each day
and the above is not what happens to me.

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

On 6 Oct 99, at 17:03, Corinna Vinschen wrote:

> Kai Henningsen wrote:
> >
> > On 5 Oct 99, at 20:51, Corinna Vinschen wrote:
> >
> > > And last but not least:
> > > - Constructive feedback always welcome.
> > > - Patches are gratefully accepted.
> >
> > Well, here's at least _some_ feedback. Excerpt from building gcc:
> >
> > ----r-xr-x   1 administ Kein       160630 Oct  6 10:15 genattrtab.o*
> > ----r-xr-x   1 administ Kein       253372 Oct  6 10:15 genattrtab.exe*
> > -rw-r--r--   1 kai      Kein       106514 Oct  6 10:15 insn-attrtab.c
> > -rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
> > ----r-xr-x   1 administ Kein       167908 Oct  6 10:15 insn-attrtab.o*
> > ----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
> > ----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*
>
> Looks like as if you have edited with ntsec but compiled without it.
> Would you be so kind to check this out?

All of these were created from the same "make bootstrap" run.
That's what I find so confusing.

> Another one: Are you sure to have only one cygwin1.dll in $PATH
> search path?

Well, I have some cygwin1.dll.something in the same directory as
the one to use, but I wouldn't expect those to be used.

(check environment)

And yes, it's exported (actually set by the .bat that starts bash).

Hmm. Maybe someone there clobbers the CYGWIN variable? <find
| xargs grep -w CYGWIN> Nope, at least nothing obvious.

Oh! Silly of me. Of _course_. It's the mingw gcc. Obviously, it won't
care about ntsec.

Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]

On 6 Oct 99, at 17:03, Corinna Vinschen wrote:

> Kai Henningsen wrote:
> >
> > On 5 Oct 99, at 20:51, Corinna Vinschen wrote:
> >
> > > And last but not least:
> > > - Constructive feedback always welcome.
> > > - Patches are gratefully accepted.
> >
> > Well, here's at least _some_ feedback. Excerpt from building gcc:
> >
> > ----r-xr-x   1 administ Kein       160630 Oct  6 10:15 genattrtab.o*
> > ----r-xr-x   1 administ Kein       253372 Oct  6 10:15 genattrtab.exe*
> > -rw-r--r--   1 kai      Kein       106514 Oct  6 10:15 insn-attrtab.c
> > -rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
> > ----r-xr-x   1 administ Kein       167908 Oct  6 10:15 insn-attrtab.o*
> > ----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
> > ----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*
>
> Looks like as if you have edited with ntsec but compiled without it.
> Would you be so kind to check this out?

All of these were created from the same "make bootstrap" run.
That's what I find so confusing.

> Another one: Are you sure to have only one cygwin1.dll in $PATH
> search path?

Well, I have some cygwin1.dll.something in the same directory as
the one to use, but I wouldn't expect those to be used.

(check environment)

And yes, it's exported (actually set by the .bat that starts bash).

Hmm. Maybe someone there clobbers the CYGWIN variable? <find
| xargs grep -w CYGWIN> Nope, at least nothing obvious.

Oh! Silly of me. Of _course_. It's the mingw gcc. Obviously, it won't
care about ntsec.

Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Corinna Vinschen]

Kai Henningsen wrote:
> 
> On 5 Oct 99, at 20:51, Corinna Vinschen wrote:
> 
> > And last but not least:
> > - Constructive feedback always welcome.
> > - Patches are gratefully accepted.
> 
> Well, here's at least _some_ feedback. Excerpt from building gcc:
> 
> ----r-xr-x   1 administ Kein       160630 Oct  6 10:15 genattrtab.o*
> ----r-xr-x   1 administ Kein       253372 Oct  6 10:15 genattrtab.exe*
> -rw-r--r--   1 kai      Kein       106514 Oct  6 10:15 insn-attrtab.c
> -rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
> ----r-xr-x   1 administ Kein       167908 Oct  6 10:15 insn-attrtab.o*
> ----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
> ----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*

Looks like as if you have edited with ntsec but compiled without it.
Would you be so kind to check this out?
Another one: Are you sure to have only one cygwin1.dll in $PATH
search path?

> Strange.

Yep. But this should have a simple solution. I'm using ntsec each day
and the above is not what happens to me.

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]

On 5 Oct 99, at 20:51, Corinna Vinschen wrote:

> And last but not least:
> - Constructive feedback always welcome.
> - Patches are gratefully accepted.

Well, here's at least _some_ feedback. Excerpt from building gcc:

----r-xr-x   1 administ Kein       160630 Oct  6 10:15 genattrtab.o*
----r-xr-x   1 administ Kein       253372 Oct  6 10:15 genattrtab.exe*
-rw-r--r--   1 kai      Kein       106514 Oct  6 10:15 insn-attrtab.c
-rw-r--r--   1 kai      Kein            0 Oct  6 10:15 s-attrtab
----r-xr-x   1 administ Kein       167908 Oct  6 10:15 insn-attrtab.o*
----r-xr-x   1 administ Kein       167214 Oct  6 10:15 i386.o*
----r-xr-x   1 administ Kein         8187 Oct  6 10:15 getpwd.o*

Strange.


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Corinna Vinschen]

Kai Henningsen wrote:
> 
> On 5 Oct 99, at 14:40, Corinna Vinschen wrote:
> 
> > 'ntsec' is definitely not the wrong option. 'ntsec' is the better
> > choice if you are using NTFS filesystems. 'ntea' is a hack that uses
> 
> What do I need for it, then?

Use mkpasswd and mkgroup to create /etc/passwd and /etc/group files.
In the current snapshots, the following rules are important:

- Dont use user and/or group names that are different from the
  NT account names.
  Ever:  administrators::544:
  Never: admins::544:
- Typically, group 513 is your primary group. This is `None' outside
  and `Domain Users' inside of NT domains.
  The primary group membership isn't important for `ntsec', so you
  may change your group entry in /etc/passwd to, e.g., administrators
  group:

	kai::1000:544:Kai Henningsen:/home/kai:/bin/sh

- Use `umask' command in your profile, e.g.: `umask 022'.

Try a `touch foo' and `ls -l foo'. Without `ntsec' you'll get:

  -rw-r--r-- 1 administ none        0 Oct 5 20:00 foo

With `ntsec':

  -rw-r--r-- 1 kai      administ    0 Oct 5 20:00 foo

> > And don't use an account, that is member of the administrators group.
> 
> Not really an option.

When you try `ntsec' you will see that this problem is gone.
Maybe, you get other ones... but I'm working hard in making
`ntsec' better.

And last but not least:
- Constructive feedback always welcome.
- Patches are gratefully accepted.

> 
> > In this case the file owner and the user are diverging.
> 
> Huh. NT bug?

No, NT `feature' ;-}
If a user is member of the administrators group, the administrators
group will be the owner of _every_ object that is created by him/her
(including files, processes, semaphores,...)
_if_ _not_ _explicitly_ _changed_! This job is done by `ntsec'.

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On 5 Oct 99, at 14:40, Corinna Vinschen wrote:

> 'ntsec' is definitely not the wrong option. 'ntsec' is the better
> choice if you are using NTFS filesystems. 'ntea' is a hack that uses

What do I need for it, then?

> If you are working with FAT, unfortunately, try a newer snapshot of

Nope, all NTFS.

> And don't use an account, that is member of the administrators group.

Not really an option.

> In this case the file owner and the user are diverging.

Huh. NT bug?


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Corinna Vinschen]

Earnie Boyd wrote:
> [...]
> "ntsec" is definitely the wrong option here.  If you want extended attributes
> you can turn this on with "ntea".  CAUTION: doing this on a FAT partition will
> cause file in the root of all FAT drives accessed by cygwin to grow a large
> file that isn't easily delete-able to be created.  Also, all diskettes will
> have the "EA DATA" system file as well.

'ntsec' is definitely not the wrong option. 'ntsec' is the better
choice if you are using NTFS filesystems. 'ntea' is a hack that uses
a cryptic WinNT method for creating and reading hidden file contents.
It's hard to erase them later if you need to do so. Moreover the
method to save this so called 'extended attributes' on FAT partitions
is an impertinence.

If you are working with FAT, unfortunately, try a newer snapshot of
cygwin1.dll. The simulated file ownership should do it for you.
And don't use an account, that is member of the administrators group.
In this case the file owner and the user are diverging.

Regards,
Corinna

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Earnie Boyd]

--- Kai Henningsen <kai@cats.ms> wrote:
> On 5 Oct 99, at 5:29, Glenn Spell wrote:
> 
> > On 5 Oct 1999 around 10:59AM (+0200) Kai Henningsen wrote:
> >
> > > On 5 Oct 99, at 10:15, I wrote:
> > >
> > > > I'm seeing this every time I ./configure something. Anybody know
> > > > what is going on?
> > > >
> > > > Sure doesn't _look_ unwritable. Besides, the very same script
> > > > just created it.
> >
> > It's unwritable by anyone other the owner of the file.
> >
> > > Well, it's "test -w" failing. Obviously because of this:
> > > bash-2.02$ id
> > > uid=1000(kai) gid=513(Kein) groups=513(Kein)
> >       ^^^^
> > > bash-2.02$ chmod a+w test
> >

This is a reported and known bug.  Have you tried it with a snapshot?

> > If you're using a recent snapshot, setting "ntsec" in your CYGWIN
> > variable may cause chmod to work correctly. (I say "may" because I
> > really don't know. I don't run NT.) Historically, chmod returns
> > without error on Cygwin but does nothing.
> >

"ntsec" is definitely the wrong option here.  If you want extended attributes
you can turn this on with "ntea".  CAUTION: doing this on a FAT partition will
cause file in the root of all FAT drives accessed by cygwin to grow a large
file that isn't easily delete-able to be created.  Also, all diskettes will
have the "EA DATA" system file as well.

> > > bash-2.02$ ls -la test
> > > -rw-r--r-- 1 544 Kein 0 Oct 5 09:57 test
> >                ^^^
> > You (UID 1000) don't own the file, UID 544 (administrator) owns
> > it. (I guess you already knew that. :-)
> 
> What I don't understand is how this happens. After all, I created the
> file. And I _can_ write to the file. Something is very wrong here.
> 
> > You need to login as administrator

Kai is already in the administrators group which makes him an administrator. 
This also makes all files created owned by the adminstrator.  The real problem
is the test -w bug.

I suggest trying a more recent snapshot.  Caveat: save any files that you
replace as you may need to backout.


=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >

Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >

(If you respond to the list, then please don't cc me)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On 5 Oct 99, at 10:15, I  wrote:

> I'm seeing this every time I ./configure something. Anybody know
> what is going on?
>
> bash-2.02$ find . -name "*cach*" -ls
> 363270609    0 -rw-r--r--   1 544      Kein            0 Oct 04 14:11 ./config.cache
> bash-2.02$
>
> Sure doesn't _look_ unwritable. Besides, the very same script just
> created it.

Well, it's "test -w" failing. Obviously because of this:

bash-2.02$ touch test
bash-2.02$ ls -la test
-rw-r--r--   1 544      Kein            0 Oct  5 09:57 test
bash-2.02$ id
uid=1000(kai) gid=513(Kein) groups=513(Kein)
bash-2.02$ chmod a+w test
bash-2.02$ ls -la test
-rw-r--r--   1 544      Kein            0 Oct  5 09:57 test
bash-2.02$

But that just shifts the confusion somewhere else.

Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Glenn Spell]

On 5 Oct 1999 around 10:59AM (+0200) Kai Henningsen wrote:

> On 5 Oct 99, at 10:15, I wrote:
>
> > I'm seeing this every time I ./configure something. Anybody know
> > what is going on?
> > 
> > Sure doesn't _look_ unwritable. Besides, the very same script
> > just created it.

It's unwritable by anyone other the owner of the file.

> Well, it's "test -w" failing. Obviously because of this:
> bash-2.02$ id
> uid=1000(kai) gid=513(Kein) groups=513(Kein)
      ^^^^
> bash-2.02$ chmod a+w test

If you're using a recent snapshot, setting "ntsec" in your CYGWIN
variable may cause chmod to work correctly. (I say "may" because I
really don't know. I don't run NT.) Historically, chmod returns
without error on Cygwin but does nothing.

> bash-2.02$ ls -la test
> -rw-r--r-- 1 544 Kein 0 Oct 5 09:57 test
               ^^^
You (UID 1000) don't own the file, UID 544 (administrator) owns
it. (I guess you already knew that. :-)

You need to login as administrator or wait for someone else to
provide information on how to enable ntsec and Unix permissions.

-glenn

-- 
  ________________________________________      _       _____
 )                                        )_ _ (__\____o /_/_ |
 )    Glenn Spell <glenn@gs.fay.nc.us>    )     >-----._/_/__]>
 )________________________________________)               `0  |

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

On 5 Oct 99, at 5:29, Glenn Spell wrote:

> On 5 Oct 1999 around 10:59AM (+0200) Kai Henningsen wrote:
>
> > On 5 Oct 99, at 10:15, I wrote:
> >
> > > I'm seeing this every time I ./configure something. Anybody know
> > > what is going on?
> > >
> > > Sure doesn't _look_ unwritable. Besides, the very same script
> > > just created it.
>
> It's unwritable by anyone other the owner of the file.
>
> > Well, it's "test -w" failing. Obviously because of this:
> > bash-2.02$ id
> > uid=1000(kai) gid=513(Kein) groups=513(Kein)
>       ^^^^
> > bash-2.02$ chmod a+w test
>
> If you're using a recent snapshot, setting "ntsec" in your CYGWIN
> variable may cause chmod to work correctly. (I say "may" because I
> really don't know. I don't run NT.) Historically, chmod returns
> without error on Cygwin but does nothing.
>
> > bash-2.02$ ls -la test
> > -rw-r--r-- 1 544 Kein 0 Oct 5 09:57 test
>                ^^^
> You (UID 1000) don't own the file, UID 544 (administrator) owns
> it. (I guess you already knew that. :-)

What I don't understand is how this happens. After all, I created the
file. And I _can_ write to the file. Something is very wrong here.

> You need to login as administrator

I don't consider that an option. Besides, I don't get any extra rights
that way.



Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

On 5 Oct 99, at 5:29, Glenn Spell wrote:

> On 5 Oct 1999 around 10:59AM (+0200) Kai Henningsen wrote:
>
> > On 5 Oct 99, at 10:15, I wrote:
> >
> > > I'm seeing this every time I ./configure something. Anybody know
> > > what is going on?
> > >
> > > Sure doesn't _look_ unwritable. Besides, the very same script
> > > just created it.
>
> It's unwritable by anyone other the owner of the file.
>
> > Well, it's "test -w" failing. Obviously because of this:
> > bash-2.02$ id
> > uid=1000(kai) gid=513(Kein) groups=513(Kein)
>       ^^^^
> > bash-2.02$ chmod a+w test
>
> If you're using a recent snapshot, setting "ntsec" in your CYGWIN
> variable may cause chmod to work correctly. (I say "may" because I
> really don't know. I don't run NT.) Historically, chmod returns
> without error on Cygwin but does nothing.
>
> > bash-2.02$ ls -la test
> > -rw-r--r-- 1 544 Kein 0 Oct 5 09:57 test
>                ^^^
> You (UID 1000) don't own the file, UID 544 (administrator) owns
> it. (I guess you already knew that. :-)

What I don't understand is how this happens. After all, I created the
file. And I _can_ write to the file. Something is very wrong here.

> You need to login as administrator

I don't consider that an option. Besides, I don't get any extra rights
that way.



Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Glenn Spell]

On 5 Oct 1999 around 10:59AM (+0200) Kai Henningsen wrote:

> On 5 Oct 99, at 10:15, I wrote:
>
> > I'm seeing this every time I ./configure something. Anybody know
> > what is going on?
> > 
> > Sure doesn't _look_ unwritable. Besides, the very same script
> > just created it.

It's unwritable by anyone other the owner of the file.

> Well, it's "test -w" failing. Obviously because of this:
> bash-2.02$ id
> uid=1000(kai) gid=513(Kein) groups=513(Kein)
      ^^^^
> bash-2.02$ chmod a+w test

If you're using a recent snapshot, setting "ntsec" in your CYGWIN
variable may cause chmod to work correctly. (I say "may" because I
really don't know. I don't run NT.) Historically, chmod returns
without error on Cygwin but does nothing.

> bash-2.02$ ls -la test
> -rw-r--r-- 1 544 Kein 0 Oct 5 09:57 test
               ^^^
You (UID 1000) don't own the file, UID 544 (administrator) owns
it. (I guess you already knew that. :-)

You need to login as administrator or wait for someone else to
provide information on how to enable ntsec and Unix permissions.

-glenn

-- 
  ________________________________________      _       _____
 )                                        )_ _ (__\____o /_/_ |
 )    Glenn Spell <glenn@gs.fay.nc.us>    )     >-----._/_/__]>
 )________________________________________)               `0  |

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]

On 5 Oct 99, at 10:15, I  wrote:

> I'm seeing this every time I ./configure something. Anybody know
> what is going on?
>
> bash-2.02$ find . -name "*cach*" -ls
> 363270609    0 -rw-r--r--   1 544      Kein            0 Oct 04 14:11 ./config.cache
> bash-2.02$
>
> Sure doesn't _look_ unwritable. Besides, the very same script just
> created it.

Well, it's "test -w" failing. Obviously because of this:

bash-2.02$ touch test
bash-2.02$ ls -la test
-rw-r--r--   1 544      Kein            0 Oct  5 09:57 test
bash-2.02$ id
uid=1000(kai) gid=513(Kein) groups=513(Kein)
bash-2.02$ chmod a+w test
bash-2.02$ ls -la test
-rw-r--r--   1 544      Kein            0 Oct  5 09:57 test
bash-2.02$

But that just shifts the confusion somewhere else.

Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

I'm seeing this every time I ./configure something. Anybody know
what is going on?

bash-2.02$ find . -name "*cach*" -ls
363270609    0 -rw-r--r--   1 544      Kein            0 Oct 04 14:11 ./config.cache
bash-2.02$

Sure doesn't _look_ unwritable. Besides, the very same script just
created it.


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

not updating unwritable cache ../config.cache

[Kai Henningsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

I'm seeing this every time I ./configure something. Anybody know
what is going on?

bash-2.02$ find . -name "*cach*" -ls
363270609    0 -rw-r--r--   1 544      Kein            0 Oct 04 14:11 ./config.cache
bash-2.02$

Sure doesn't _look_ unwritable. Besides, the very same script just
created it.


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com