RE: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Nellis, Kenneth 
> From: Eric Blake
> On 07/20/2011 12:05 PM, Reid Thompson wrote:
> > Is this broken?  Or a known windows/cygwin discrepancy?  Or am I
> missing
> > something with my posix/windows file permissions settings
> 
> If you are running as an administrator, that might explain it.  Admins
> can alter any file regardless of permissions, in which case [ -w is
> telling you the truth that under your current uid, you can indeed write
> to the file.
> 
> This is a feature of access(file,W_OK), and not a bug.

FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
seeing the same thing:

$ touch afile
$ chmod 444 afile
$ ls -l
total 0
-r--r--r-- 1 knellis knellis 0 Jul 21 08:36 afile
$ [ -w afile ] && echo writable || echo not writable
writable
$ echo abc >> afile
$ cat afile
abc
$ ls -l
total 1
-r--r--r-- 1 knellis knellis 4 Jul 21 08:37 afile
$

--Ken Nellis

Re: [bash or DLL] Memory leak in childs

2011-07-21 Thread AZ 9901 
Hello,

Thank you very much for your feedback !
I come back to the first point, memory leak when bash forks (seen in
example loops).

Following your advice and BLODA documentation, I made tests in a fresh
/ newly installed virtual environment (Windows XP / VirtualBox).
I did not notice any problem at all.
So I decided to run tests booting my suffering environment in safe
mode (F8 at boot time, then safe mode).
Once again, no problem at all.

So yes, memory leak is due to background programs which interfer with the OS.

Unfortunately, it is sometime not possible to find out which component
is responsible, and to clean it (production environment,
customers...).
So, my next question is, do you have any advice to avoid or limit memory leak ?
- specific bash scripting method / tips ;
- program to call to free memory ;
- another method to fork that would avoid memory leak (patched DLL,
wrokaround...) ;
- ... ?

Thank you very much !

Best regards,

Benjamin

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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Corinna Vinschen 
On Jul 21 07:43, Nellis, Kenneth wrote:
> > From: Eric Blake
> > On 07/20/2011 12:05 PM, Reid Thompson wrote:
> > > Is this broken?  Or a known windows/cygwin discrepancy?  Or am I
> > missing
> > > something with my posix/windows file permissions settings
> > 
> > If you are running as an administrator, that might explain it.  Admins
> > can alter any file regardless of permissions, in which case [ -w is
> > telling you the truth that under your current uid, you can indeed write
> > to the file.
> > 
> > This is a feature of access(file,W_OK), and not a bug.
> 
> FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
> seeing the same thing:
> 
> $ touch afile
> $ chmod 444 afile
> $ ls -l
> total 0
> -r--r--r-- 1 knellis knellis 0 Jul 21 08:36 afile
> $ [ -w afile ] && echo writable || echo not writable
> writable
> $ echo abc >> afile
> $ cat afile
> abc
> $ ls -l
> total 1
> -r--r--r-- 1 knellis knellis 4 Jul 21 08:37 afile
> $

What system?  XP, Vista?  7?
What's the output of `id'?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Re: ioctl: FIONREAD and ENOTTY

2011-07-21 Thread Corinna Vinschen 
On Jul 20 17:37, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-07-20 at 17:46 +0200, Corinna Vinschen wrote:
> > On Jul 20 03:11, Yaakov (Cygwin/X) wrote:
> > > On Linux, ioctl(2) returns several different errors[1]:
> > > 
> > > EBADF  d is not a valid descriptor.
> > > EFAULT argp references an inaccessible memory area.
> > > EINVAL Request or argp is not valid.
> > > ENOTTY d is not associated with a character special device.
> > > ENOTTY The specified request does not apply to the kind of object that
> > >the descriptor d references.
> > > 
> > > In the case of FIONREAD, Cygwin doesn't seem to distinguish between
> > > EINVAL and ENOTTY, and this causes at least one major bug:
> > > 
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35536
> > > 
> > > I have patched GCJ and GNU classpath to work around it, but this really
> > > needs to be fixed in Cygwin itself.
> > 
> > Would this patch be sufficient?
> > 
> > Index: fhandler.cc
> > ===
> > RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v
> > retrieving revision 1.397
> > diff -u -p -r1.397 fhandler.cc
> > --- fhandler.cc 5 Jul 2011 12:02:10 -   1.397
> > +++ fhandler.cc 20 Jul 2011 15:46:40 -
> > @@ -1151,6 +1151,10 @@ fhandler_base::ioctl (unsigned int cmd, 
> >set_nonblocking (*(int *) buf);
> >res = 0;
> >break;
> > +case FIONREAD:
> > +  set_errno (ENOTTY);
> > +  res = -1;
> > +  break;
> >  default:
> >set_errno (EINVAL);
> >res = -1;
> 
> Given my testcases, give me a few days to check this out.

Ok, but the patch doesn't build as is.  You have to add

  #include 

to get the FIONREAD definition.  Sorry about that.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Re: ioctl: FIONREAD and ENOTTY

2011-07-21 Thread Christopher Faylor 
On Thu, Jul 21, 2011 at 04:39:31PM +0200, Corinna Vinschen wrote:
>On Jul 20 17:37, Yaakov (Cygwin/X) wrote:
>> On Wed, 2011-07-20 at 17:46 +0200, Corinna Vinschen wrote:
>> > On Jul 20 03:11, Yaakov (Cygwin/X) wrote:
>> > > On Linux, ioctl(2) returns several different errors[1]:
>> > > 
>> > > EBADF  d is not a valid descriptor.
>> > > EFAULT argp references an inaccessible memory area.
>> > > EINVAL Request or argp is not valid.
>> > > ENOTTY d is not associated with a character special device.
>> > > ENOTTY The specified request does not apply to the kind of object that
>> > >the descriptor d references.
>> > > 
>> > > In the case of FIONREAD, Cygwin doesn't seem to distinguish between
>> > > EINVAL and ENOTTY, and this causes at least one major bug:
>> > > 
>> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35536
>> > > 
>> > > I have patched GCJ and GNU classpath to work around it, but this really
>> > > needs to be fixed in Cygwin itself.
>> > 
>> > Would this patch be sufficient?
>> > 
>> > Index: fhandler.cc
>> > ===
>> > RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v
>> > retrieving revision 1.397
>> > diff -u -p -r1.397 fhandler.cc
>> > --- fhandler.cc5 Jul 2011 12:02:10 -   1.397
>> > +++ fhandler.cc20 Jul 2011 15:46:40 -
>> > @@ -1151,6 +1151,10 @@ fhandler_base::ioctl (unsigned int cmd, 
>> >set_nonblocking (*(int *) buf);
>> >res = 0;
>> >break;
>> > +case FIONREAD:
>> > +  set_errno (ENOTTY);
>> > +  res = -1;
>> > +  break;
>> >  default:
>> >set_errno (EINVAL);
>> >res = -1;
>> 
>> Given my testcases, give me a few days to check this out.
>
>Ok, but the patch doesn't build as is.  You have to add
>
>  #include 
>
>to get the FIONREAD definition.  Sorry about that.

Btw, I don't think the above is sufficient.  I think you'll have to add a
similar test to other fhandlers (like fhandler_windows) which completely
implement ioctl without reverting to fhandler_base.

cgf

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

Re: ioctl: FIONREAD and ENOTTY

2011-07-21 Thread Corinna Vinschen 
On Jul 21 13:05, Christopher Faylor wrote:
> On Thu, Jul 21, 2011 at 04:39:31PM +0200, Corinna Vinschen wrote:
> >On Jul 20 17:37, Yaakov (Cygwin/X) wrote:
> >> On Wed, 2011-07-20 at 17:46 +0200, Corinna Vinschen wrote:
> >> > On Jul 20 03:11, Yaakov (Cygwin/X) wrote:
> >> > > On Linux, ioctl(2) returns several different errors[1]:
> >> > > 
> >> > > EBADF  d is not a valid descriptor.
> >> > > EFAULT argp references an inaccessible memory area.
> >> > > EINVAL Request or argp is not valid.
> >> > > ENOTTY d is not associated with a character special device.
> >> > > ENOTTY The specified request does not apply to the kind of object that
> >> > >the descriptor d references.
> >> > > 
> >> > > In the case of FIONREAD, Cygwin doesn't seem to distinguish between
> >> > > EINVAL and ENOTTY, and this causes at least one major bug:
> >> > > 
> >> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35536
> >> > > 
> >> > > I have patched GCJ and GNU classpath to work around it, but this really
> >> > > needs to be fixed in Cygwin itself.
> >> > 
> >> > Would this patch be sufficient?
> >> > 
> >> > Index: fhandler.cc
> >> > ===
> >> > RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v
> >> > retrieving revision 1.397
> >> > diff -u -p -r1.397 fhandler.cc
> >> > --- fhandler.cc  5 Jul 2011 12:02:10 -   1.397
> >> > +++ fhandler.cc  20 Jul 2011 15:46:40 -
> >> > @@ -1151,6 +1151,10 @@ fhandler_base::ioctl (unsigned int cmd, 
> >> >set_nonblocking (*(int *) buf);
> >> >res = 0;
> >> >break;
> >> > +case FIONREAD:
> >> > +  set_errno (ENOTTY);
> >> > +  res = -1;
> >> > +  break;
> >> >  default:
> >> >set_errno (EINVAL);
> >> >res = -1;
> >> 
> >> Given my testcases, give me a few days to check this out.
> >
> >Ok, but the patch doesn't build as is.  You have to add
> >
> >  #include 
> >
> >to get the FIONREAD definition.  Sorry about that.
> 
> Btw, I don't think the above is sufficient.  I think you'll have to add a
> similar test to other fhandlers (like fhandler_windows) which completely
> implement ioctl without reverting to fhandler_base.

Hmm, isn't that just a bug in these ioctl methods?  I think they
all should fall through to fhandler_base::ioctl.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Re: [bash or DLL] Memory leak in childs

2011-07-21 Thread Larry Hall (Cygwin) 

On 7/21/2011 9:12 AM, AZ 9901 wrote:




Following your advice and BLODA documentation, I made tests in a fresh
/ newly installed virtual environment (Windows XP / VirtualBox).
I did not notice any problem at all.
So I decided to run tests booting my suffering environment in safe
mode (F8 at boot time, then safe mode).
Once again, no problem at all.

So yes, memory leak is due to background programs which interfer with the OS.

Unfortunately, it is sometime not possible to find out which component
is responsible, and to clean it (production environment,
customers...).
So, my next question is, do you have any advice to avoid or limit memory leak ?
- specific bash scripting method / tips ;
- program to call to free memory ;
- another method to fork that would avoid memory leak (patched DLL,
wrokaround...) ;
- ... ?


Your best bet is to report the problem to the provider of the product
that's interfering.  You should be able to zero in on the product by
booting into safe mode and then turning on, one by one, the services
that safe mode omits and running the test.  When you see the problem
again, you'll know what product is responsible.

Another alternative is to try a snapshot.



There have been some recent changes that could help in your situation.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Larry Hall (Cygwin) 

On 7/21/2011 9:31 AM, Corinna Vinschen wrote:

On Jul 21 07:43, Nellis, Kenneth wrote:

From: Eric Blake
On 07/20/2011 12:05 PM, Reid Thompson wrote:

Is this broken?  Or a known windows/cygwin discrepancy?  Or am I

missing

something with my posix/windows file permissions settings


If you are running as an administrator, that might explain it.  Admins
can alter any file regardless of permissions, in which case [ -w is
telling you the truth that under your current uid, you can indeed write
to the file.

This is a feature of access(file,W_OK), and not a bug.


FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
seeing the same thing:

$ touch afile
$ chmod 444 afile
$ ls -l
total 0
-r--r--r-- 1 knellis knellis 0 Jul 21 08:36 afile
$ [ -w afile ]&&  echo writable || echo not writable
writable
$ echo abc>>  afile
$ cat afile
abc
$ ls -l
total 1
-r--r--r-- 1 knellis knellis 4 Jul 21 08:37 afile
$


What system?  XP, Vista?  7?
What's the output of `id'?


Or even . ;-)


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Corinna Vinschen 
On Jul 21 14:51, Larry Hall (Cygwin) wrote:
> On 7/21/2011 9:31 AM, Corinna Vinschen wrote:
> >On Jul 21 07:43, Nellis, Kenneth wrote:
> >>>From: Eric Blake
> >>>On 07/20/2011 12:05 PM, Reid Thompson wrote:
> Is this broken?  Or a known windows/cygwin discrepancy?  Or am I
> >>>missing
> something with my posix/windows file permissions settings
> >>>
> >>>If you are running as an administrator, that might explain it.  Admins
> >>>can alter any file regardless of permissions, in which case [ -w is
> >>>telling you the truth that under your current uid, you can indeed write
> >>>to the file.
> >>>
> >>>This is a feature of access(file,W_OK), and not a bug.
> >>
> >>FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
> >>seeing the same thing:
> >>
> >>$ touch afile
> >>$ chmod 444 afile
> >>$ ls -l
> >>total 0
> >>-r--r--r-- 1 knellis knellis 0 Jul 21 08:36 afile
> >>$ [ -w afile ]&&  echo writable || echo not writable
> >>writable
> >>$ echo abc>>  afile
> >>$ cat afile
> >>abc
> >>$ ls -l
> >>total 1
> >>-r--r--r-- 1 knellis knellis 4 Jul 21 08:37 afile
> >>$
> >
> >What system?  XP, Vista?  7?
> >What's the output of `id'?
> 
> Or even . ;-)

In this case I don't think so.  I can't reproduce this with 1.7.9
either, unless the SE_BACKUP_NAME privilege is in the user token and
can be enabled by Cygwin.  This is usually only the case if the user
is member of the Administrators group and the shell is not running
with a restricted token (UAC).


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Re: ioctl: FIONREAD and ENOTTY

2011-07-21 Thread Christopher Faylor 
On Thu, Jul 21, 2011 at 07:47:17PM +0200, Corinna Vinschen wrote:
>On Jul 21 13:05, Christopher Faylor wrote:
>> On Thu, Jul 21, 2011 at 04:39:31PM +0200, Corinna Vinschen wrote:
>> >On Jul 20 17:37, Yaakov (Cygwin/X) wrote:
>> >> On Wed, 2011-07-20 at 17:46 +0200, Corinna Vinschen wrote:
>> >> > On Jul 20 03:11, Yaakov (Cygwin/X) wrote:
>> >> > > On Linux, ioctl(2) returns several different errors[1]:
>> >> > > 
>> >> > > EBADF  d is not a valid descriptor.
>> >> > > EFAULT argp references an inaccessible memory area.
>> >> > > EINVAL Request or argp is not valid.
>> >> > > ENOTTY d is not associated with a character special device.
>> >> > > ENOTTY The specified request does not apply to the kind of object that
>> >> > >the descriptor d references.
>> >> > > 
>> >> > > In the case of FIONREAD, Cygwin doesn't seem to distinguish between
>> >> > > EINVAL and ENOTTY, and this causes at least one major bug:
>> >> > > 
>> >> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35536
>> >> > > 
>> >> > > I have patched GCJ and GNU classpath to work around it, but this 
>> >> > > really
>> >> > > needs to be fixed in Cygwin itself.
>> >> > 
>> >> > Would this patch be sufficient?
>> >> > 
>> >> > Index: fhandler.cc
>> >> > ===
>> >> > RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v
>> >> > retrieving revision 1.397
>> >> > diff -u -p -r1.397 fhandler.cc
>> >> > --- fhandler.cc 5 Jul 2011 12:02:10 -   1.397
>> >> > +++ fhandler.cc 20 Jul 2011 15:46:40 -
>> >> > @@ -1151,6 +1151,10 @@ fhandler_base::ioctl (unsigned int cmd, 
>> >> >set_nonblocking (*(int *) buf);
>> >> >res = 0;
>> >> >break;
>> >> > +case FIONREAD:
>> >> > +  set_errno (ENOTTY);
>> >> > +  res = -1;
>> >> > +  break;
>> >> >  default:
>> >> >set_errno (EINVAL);
>> >> >res = -1;
>> >> 
>> >> Given my testcases, give me a few days to check this out.
>> >
>> >Ok, but the patch doesn't build as is.  You have to add
>> >
>> >  #include 
>> >
>> >to get the FIONREAD definition.  Sorry about that.
>> 
>> Btw, I don't think the above is sufficient.  I think you'll have to add a
>> similar test to other fhandlers (like fhandler_windows) which completely
>> implement ioctl without reverting to fhandler_base.
>
>Hmm, isn't that just a bug in these ioctl methods?  I think they
>all should fall through to fhandler_base::ioctl.

Yep.  I think you're right.  I'll handle that if you want.

cgf

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

Re: ioctl: FIONREAD and ENOTTY

2011-07-21 Thread Christopher Faylor 
On Thu, Jul 21, 2011 at 03:57:46PM -0400, Christopher Faylor wrote:
>On Thu, Jul 21, 2011 at 07:47:17PM +0200, Corinna Vinschen wrote:
>>On Jul 21 13:05, Christopher Faylor wrote:
>>> On Thu, Jul 21, 2011 at 04:39:31PM +0200, Corinna Vinschen wrote:
>>> >On Jul 20 17:37, Yaakov (Cygwin/X) wrote:
>>> >> On Wed, 2011-07-20 at 17:46 +0200, Corinna Vinschen wrote:
>>> >> > On Jul 20 03:11, Yaakov (Cygwin/X) wrote:
>>> >> > > On Linux, ioctl(2) returns several different errors[1]:
>>> >> > > 
>>> >> > > EBADF  d is not a valid descriptor.
>>> >> > > EFAULT argp references an inaccessible memory area.
>>> >> > > EINVAL Request or argp is not valid.
>>> >> > > ENOTTY d is not associated with a character special device.
>>> >> > > ENOTTY The specified request does not apply to the kind of object 
>>> >> > > that
>>> >> > >the descriptor d references.
>>> >> > > 
>>> >> > > In the case of FIONREAD, Cygwin doesn't seem to distinguish between
>>> >> > > EINVAL and ENOTTY, and this causes at least one major bug:
>>> >> > > 
>>> >> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35536
>>> >> > > 
>>> >> > > I have patched GCJ and GNU classpath to work around it, but this 
>>> >> > > really
>>> >> > > needs to be fixed in Cygwin itself.
>>> >> > 
>>> >> > Would this patch be sufficient?
>>> >> > 
>>> >> > Index: fhandler.cc
>>> >> > ===
>>> >> > RCS file: /cvs/src/src/winsup/cygwin/fhandler.cc,v
>>> >> > retrieving revision 1.397
>>> >> > diff -u -p -r1.397 fhandler.cc
>>> >> > --- fhandler.cc5 Jul 2011 12:02:10 -   1.397
>>> >> > +++ fhandler.cc20 Jul 2011 15:46:40 -
>>> >> > @@ -1151,6 +1151,10 @@ fhandler_base::ioctl (unsigned int cmd, 
>>> >> >set_nonblocking (*(int *) buf);
>>> >> >res = 0;
>>> >> >break;
>>> >> > +case FIONREAD:
>>> >> > +  set_errno (ENOTTY);
>>> >> > +  res = -1;
>>> >> > +  break;
>>> >> >  default:
>>> >> >set_errno (EINVAL);
>>> >> >res = -1;
>>> >> 
>>> >> Given my testcases, give me a few days to check this out.
>>> >
>>> >Ok, but the patch doesn't build as is.  You have to add
>>> >
>>> >  #include 
>>> >
>>> >to get the FIONREAD definition.  Sorry about that.
>>> 
>>> Btw, I don't think the above is sufficient.  I think you'll have to add a
>>> similar test to other fhandlers (like fhandler_windows) which completely
>>> implement ioctl without reverting to fhandler_base.
>>
>>Hmm, isn't that just a bug in these ioctl methods?  I think they
>>all should fall through to fhandler_base::ioctl.
>
>Yep.  I think you're right.  I'll handle that if you want.

I made this modification and added the above patch as well.  We can
always pull it out or modify it if it doesn't do the right thing.

A snapshot is building now.

cgf

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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Larry Hall (Cygwin) 

On 7/21/2011 3:01 PM, Corinna Vinschen wrote:

On Jul 21 14:51, Larry Hall (Cygwin) wrote:

On 7/21/2011 9:31 AM, Corinna Vinschen wrote:

On Jul 21 07:43, Nellis, Kenneth wrote:

From: Eric Blake
On 07/20/2011 12:05 PM, Reid Thompson wrote:

Is this broken?  Or a known windows/cygwin discrepancy?  Or am I

missing

something with my posix/windows file permissions settings


If you are running as an administrator, that might explain it.  Admins
can alter any file regardless of permissions, in which case [ -w is
telling you the truth that under your current uid, you can indeed write
to the file.

This is a feature of access(file,W_OK), and not a bug.


FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
seeing the same thing:

$ touch afile
$ chmod 444 afile
$ ls -l
total 0
-r--r--r-- 1 knellis knellis 0 Jul 21 08:36 afile
$ [ -w afile ]&&   echo writable || echo not writable
writable
$ echo abc>>   afile
$ cat afile
abc
$ ls -l
total 1
-r--r--r-- 1 knellis knellis 4 Jul 21 08:37 afile
$


What system?  XP, Vista?  7?
What's the output of `id'?


Or even. ;-)


In this case I don't think so.  I can't reproduce this with 1.7.9
either, unless the SE_BACKUP_NAME privilege is in the user token and
can be enabled by Cygwin.  This is usually only the case if the user
is member of the Administrators group and the shell is not running
with a restricted token (UAC).


Yikes!  I didn't even notice that I pasted the wrong link.  I meant
.  Sorry for the noise. :-(

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

RE: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Nellis, Kenneth 
> From: Corinna Vinschen
> On Jul 21 07:43, Nellis, Kenneth wrote:
> > FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
> > seeing the same thing:
> What system?  XP, Vista?  7?
> What's the output of `id'?

$ /usr/lib/csih/winProductName
Microsoft Windows XP Professional Service Pack 3 (build 2600)
$ id
uid=12779(knellis) gid=10545(knellis) 
groups=10545(knellis),0(root),544(Administrators),545(Users)
$ uname -r
1.7.9(0.237/5/3)
$

cygcheck -svr output attached

--Ken Nellis


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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Larry Hall (Cygwin) 

On 7/21/2011 5:13 PM, Nellis, Kenneth wrote:

From: Corinna Vinschen
On Jul 21 07:43, Nellis, Kenneth wrote:

FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
seeing the same thing:

What system?  XP, Vista?  7?
What's the output of `id'?


$ /usr/lib/csih/winProductName
Microsoft Windows XP Professional Service Pack 3 (build 2600)
$ id
uid=12779(knellis) gid=10545(knellis) 
groups=10545(knellis),0(root),544(Administrators),545(Users)
$ uname -r
1.7.9(0.237/5/3)
$

cygcheck -svr output attached


Thanks.  Are you doing the above steps from a directory on your C or D
drive?  If D, is it an internal drive to that machine?  If not, can
you tell us the kind of drive it is and send the results of
/usr/lib/csih/getVolInfo.exe /cygdrive/d to the list.  If you don't
have getVolInfo, please install the csih package.


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Is DBUS 1.4.x available for Cygwin?

2011-07-21 Thread nyc4bos 

Hi,

Is there a version of DBUS 1.4.10 (or 1.4.12) available
for Cygwin anywhere?

Thanks.



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

SIGHUP on pty closure

2011-07-21 Thread Marco atzeri 

looking on the mc subshell issue, I found that mc
suppose that the subshell will receive a SIGHUP
when mc exit and close the master side of pty.

Is such assumption wrong or it is a missing piece of
cygwin pty implementation ?



- extract from subshell.c --
/* Attach all our standard file descriptors to the pty */

/* This is done just before the fork, because stderr must still  */
/* be connected to the real tty during the above error messages; */
/* otherwise the user will never see them.   */

dup2 (subshell_pty_slave, STDIN_FILENO);
dup2 (subshell_pty_slave, STDOUT_FILENO);
dup2 (subshell_pty_slave, STDERR_FILENO);

close (subshell_pipe[READ]);
close (subshell_pty_slave); /* These may be FD_CLOEXEC, but just in 
case... */

/* Close master side of pty.  This is important; apart from */
/* freeing up the descriptor for use in the subshell, it also   */
/* means that when MC exits, the subshell will get a SIGHUP and */
/* exit too, because there will be no more descriptors pointing */
/* at the master side of the pty and so it will disappear.  */
close (subshell_pty);

/* Execute the subshell at last */

switch (subshell_type)
{
case BASH:
execl (shell, "bash", "-rcfile", init_file, (char *) NULL);
break;
--

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

Re: Is DBUS 1.4.x available for Cygwin?

2011-07-21 Thread Larry Hall (Cygwin) 

On 7/21/2011 5:38 PM, nyc4...@aol.com wrote:


Hi,

Is there a version of DBUS 1.4.10 (or 1.4.12) available
for Cygwin anywhere?


Not from cygwin.com, no:



Cygwin Ports gets you as close as 1.4.8.

--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Andrew DeFaria 

On 7/21/2011 2:37 PM, Larry Hall (Cygwin) wrote:

On 7/21/2011 5:13 PM, Nellis, Kenneth wrote:

From: Corinna Vinschen
On Jul 21 07:43, Nellis, Kenneth wrote:

FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
seeing the same thing:

What system?  XP, Vista?  7?
What's the output of `id'?


$ /usr/lib/csih/winProductName
Microsoft Windows XP Professional Service Pack 3 (build 2600)
$ id
uid=12779(knellis) gid=10545(knellis) 
groups=10545(knellis),0(root),544(Administrators),545(Users)

$ uname -r
1.7.9(0.237/5/3)
$

cygcheck -svr output attached


Thanks.  Are you doing the above steps from a directory on your C or D
drive?  If D, is it an internal drive to that machine?  If not, can
you tell us the kind of drive it is and send the results of
/usr/lib/csih/getVolInfo.exe /cygdrive/d to the list.  If you don't
have getVolInfo, please install the csih package.
I'm seeing the exact same behavior. I see this on my C drive (I cd'ed to 
/tmp). The drive is:


Usscandrewdl:/usr/lib/csih/getVolInfo.exe /cygdrive/c
Device Type: 7
Characteristics: 20
Volume Name: <>
Serial Number  : 2956864138
Max Filenamelength : 255
Filesystemname : 
Flags  : 700ff
  FILE_CASE_SENSITIVE_SEARCH  : TRUE
  FILE_CASE_PRESERVED_NAMES   : TRUE
  FILE_UNICODE_ON_DISK: TRUE
  FILE_PERSISTENT_ACLS: TRUE
  FILE_FILE_COMPRESSION   : TRUE
  FILE_VOLUME_QUOTAS  : TRUE
  FILE_SUPPORTS_SPARSE_FILES  : TRUE
  FILE_SUPPORTS_REPARSE_POINTS: TRUE
  FILE_SUPPORTS_REMOTE_STORAGE: FALSE
  FILE_VOLUME_IS_COMPRESSED   : FALSE
  FILE_SUPPORTS_OBJECT_IDS: TRUE
  FILE_SUPPORTS_ENCRYPTION: TRUE
  FILE_NAMED_STREAMS  : TRUE
  FILE_READ_ONLY_VOLUME   : FALSE
  FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
  FILE_SUPPORTS_TRANSACTIONS  : FALSE


--
Andrew DeFaria 
Why can we shop in a store but we can't store in a shop?


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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Larry Hall (Cygwin) 

On 7/21/2011 9:07 PM, Andrew DeFaria wrote:

I'm seeing the exact same behavior. I see this on my C drive (I cd'ed to
/tmp). The drive is:


Weird.  So what are you using?  XP and Cygwin 1.7.9 or something else?


--
Larry

_

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

I'm confused, ... domain vs. local account mappings (why diffs, how to control mappings?)

2011-07-21 Thread Linda Walsh 




For various reasons (config changes, upgrading to newer
version of samba, phase of the moon, dumb-luck/random
chance, after a latest round of samba-setup config
auditing (amongst other things),
I'm no longer getting  "device attached to sys not functioning"

(originally reported http://cygwin.com/ml/cygwin/2010-07/msg00289.html)

Now I get output that I'm not exactly sure how to interpret.

--- first local, which by itself seems almost normal):
(I split long lines and indented the continuations, also sub'ed
the long sys-uniq# with 1-2-1 for my local sys.
I use a different ## for my domain further on, down, below.
(I also sorted them by UID)

# mkpasswd -l:
SYSTEM:*:18:544:,S-1-5-18::
LocalService:*:19:544:U-NT AUTHORITY\LocalService,S-1-5-19::
NetworkService:*:20:544:U-NT AUTHORITY\NetworkService,S-1-5-20::
Guest:unused:501:513:U-athenae\Guest,\
   S-1-5-21-1-2-1-501:/home/Guest:/bin/bash
root:unused:500:513:Athenae Admin,U-athenae\root,\
   S-1-5-21-1-2-1-500:/home/root:/bin/bash
Administrators:*:544:544:,S-1-5-32-544::
law:unused:1001:513:L A Walsh,U-athenae\law,\
   S-1-5-21-1-2-1-1001:/home/law:/bin/bash


# mkgroup -l
SYSTEM:S-1-5-18:18:
None:S-1-5-21-1-2-1-513:513:
Administrators:S-1-5-32-544:544:
Users:S-1-5-32-545:545:
Guests:S-1-5-32-546:546:
Power Users:S-1-5-32-547:547:
Backup Operators:S-1-5-32-551:551:
Replicator:S-1-5-32-552:552:
Remote Desktop Users:S-1-5-32-555:555:
Network Configuration Operators:S-1-5-32-556:556:
Performance Monitor Users:S-1-5-32-558:558:
Performance Log Users:S-1-5-32-559:559:
Distributed COM Users:S-1-5-32-562:562:
IIS_IUSRS:S-1-5-32-568:568:
Cryptographic Operators:S-1-5-32-569:569:
Event Log Readers:S-1-5-32-573:573:
lawgroup:S-1-5-21-1-2-1-1005:1005:
---
so above looks ok, -- several builtin entries, and some
added local entries.

Now the Domain entries:

# mkpasswd -D:
BLISS\root:unused:10500:10513:root,U-BLISS\root,
   S-1-5-21-3-7-3-500://BLISS/root:/bin/bash
BLISS\law:unused:90026:71008:L A Walsh,U-BLISS\law,\
   S-1-5-21-3-7-3-80026://BLISS/law:/bin/bash

#mkgroup -D:
SYSTEM:S-1-5-18:18:
Print Operators:S-1-5-32-550:550:
Replicator:S-1-5-32-552:552:
Administrators:S-1-5-32-544:544:
Users:S-1-5-32-545:545:
Guests:S-1-5-32-546:546:
Power Users:S-1-5-32-547:547:
Account Operators:S-1-5-32-548:548:
Server Operators:S-1-5-32-549:549:
Backup Operators:S-1-5-32-551:551:
RAS Servers:S-1-5-32-553:553:
BLISS\Domain Admins:S-1-5-21-3-7-3-512:10512:
BLISS\Domain Controllers:S-1-5-21-3-7-3-516:10516:
BLISS\Juno:S-1-5-21-3-7-3-1462:11005:
BLISS\media:S-1-5-21-3-7-3-1017:11017:
BUILTIN\Backup Operators:S-1-5-32-551:11018:
BLISS\man:S-1-5-21-3-7-3-1028:11028:
BLISS\Trusted Local Net Users:S-1-5-21-3-7-3-50002:60002:
BLISS\lawgroup:S-1-5-21-3-7-3-61008:71008:
BLISS\scan:S-1-5-21-3-7-3-70464:80464:



Comments:
1) local user 'law', 'root' and 'guest' are all in '513'
Sid  "S-1-5-21513" is a "well known sid" for 'Domain Users'
(why it shows up as a group labeled 'non' with my local
computers id in the computer part, is confusing.

2) 'law' is in 'lawgroup' (one good thing!)
But Domain user 'root' is in group 10513, which is sorta 'broken'
like the local users mapping to 513.  It probably should have
mapped to '10512'? 


3) Why 2 Backup Operators? -- Backup Operators mapping
correctly from Sid S---551->551.
  but 'builtin\backup operators, (also 512, mapping to a different
domain-mapped UID on the local machine).

I do have Domain Admins, -512, but they aren't being mapped
to the correct local GID of '512'...
Same goes for 'Domain Controllers' (516->10516)

Conflicts?
Or design (I hope?, but how to fix the broken parts?)
Note there is a larger overlap of unprefixed groups from
the local and domain listing.  None conflict if they were
merged with dups removed, but some are in the Domain
listing, while others are only in the local listing.

So -- I take it the low-numbered groups are not prefixed because
the somehow have a "WELL KNOWN SID" property attached to them?

Hoping/presuming that's the case, how can I map the
3 domain groups:
'Domains Admins'  (i.e. 10512 -> 512)
'Domain Controllers' (10516 -> 516)
builtin/backup operators -> backup operators

(i.e. did I miss setting some 'built-in' flag somewhere?)

or, how do I prevent cygwin from adding anything to the
UID's, that way, I can have the same mapping from the DC?

(as the DC, running samba, has already done a block-jump
mapping of UID's into a higher level)

---
Guess that's the main Q how to have cygwin not add to the
UID's -- that way Domain Administrator would map to Administrator,
which is also 'correct' for Admins on Domain joined machines
(IF memory serves me correctly, I could see that making sense
as well -- as in a domain, as domain policy can lockdown/control
member machines, it could also disable local admin

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Andrew DeFaria 

On 07/21/11 19:50, Larry Hall (Cygwin) wrote:

On 7/21/2011 9:07 PM, Andrew DeFaria wrote:
I'm seeing the exact same behavior. I see this on my C drive (I cd'ed 
to /tmp). The drive is:


Weird.  So what are you using?  XP and Cygwin 1.7.9 or something else?

Yes. At work XP and 1.7.9.

Here at home it's Win 7 (VM) and 1.7.7. Still the same:

Neptune:pwd
/tmp
Neptune:df .
Filesystem   1K-blocks  Used Available Use% Mounted on
C:/cygwin 54604900  19369104  35235796  36% /
Neptune:ll afile
-r--r--r-- 1 andrew None 0 2011-07-21 22:24 afile
Neptune:[ -w afile ] && echo writable || echo not writable
writable
Neptune:echo abc >> afile
Neptune:ll afile
-r--r--r-- 1 andrew None 4 2011-07-21 22:24 afile
Neptune:uname -a
CYGWIN_NT-6.1-WOW64 Neptune 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
Neptune:


--
Andrew DeFaria 
Why are they called apartments, when they're all stuck together?


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

Re: Is DBUS 1.4.x available for Cygwin?

2011-07-21 Thread Yaakov (Cygwin/X) 
On Thu, 2011-07-21 at 17:54 -0400, Larry Hall (Cygwin) wrote:
> On 7/21/2011 5:38 PM, nyc4bos wrote:
> > Is there a version of DBUS 1.4.10 (or 1.4.12) available
> > for Cygwin anywhere?
> 
> Not from cygwin.com, no:
> 
> 
> 
> Cygwin Ports gets you as close as 1.4.8.


You know, as essential as D-Bus is nowadays (very), you'd think they'd
ANNOUNCE THEIR RELEASES somewhere?  They don't announce on any major
desktops' lists, they don't have an announce list, they're not even on
freshmeat, and to make matters worse, their *own website* is one release
behind!


Larry is, as usual, spot on; dbus-1.4.8 is available in Ports, and
1.4.12 is building as I write this.  As for the distro, its package will
be updated once GCC 4.5 goes stable.

Thanks for the heads-up.


Yaakov



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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Corinna Vinschen 
On Jul 21 16:13, Nellis, Kenneth wrote:
> > From: Corinna Vinschen
> > On Jul 21 07:43, Nellis, Kenneth wrote:
> > > FWIW, I'm not running as administrator and I'm running 1.7.9, and I'm
> > > seeing the same thing:
> > What system?  XP, Vista?  7?
> > What's the output of `id'?
> 
> $ /usr/lib/csih/winProductName
> Microsoft Windows XP Professional Service Pack 3 (build 2600)
> $ id
> uid=12779(knellis) gid=10545(knellis) 
> groups=10545(knellis),0(root),544(Administrators),545(Users)

So you are member of the administrators group.  Problem solved.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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

Re: [ -w filename ] returns true when permissions are -r--r--r--

2011-07-21 Thread Corinna Vinschen 
On Jul 21 22:25, Andrew DeFaria wrote:
> On 07/21/11 19:50, Larry Hall (Cygwin) wrote:
> >On 7/21/2011 9:07 PM, Andrew DeFaria wrote:
> >>I'm seeing the exact same behavior. I see this on my C drive (I
> >>cd'ed to /tmp). The drive is:
> >
> >Weird.  So what are you using?  XP and Cygwin 1.7.9 or something else?
> Yes. At work XP and 1.7.9.
> 
> Here at home it's Win 7 (VM) and 1.7.7. Still the same:
> 
> Neptune:pwd
> /tmp
> Neptune:df .
> Filesystem   1K-blocks  Used Available Use% Mounted on
> C:/cygwin 54604900  19369104  35235796  36% /
> Neptune:ll afile
> -r--r--r-- 1 andrew None 0 2011-07-21 22:24 afile
> Neptune:[ -w afile ] && echo writable || echo not writable
> writable
> Neptune:echo abc >> afile
> Neptune:ll afile
> -r--r--r-- 1 andrew None 4 2011-07-21 22:24 afile
> Neptune:uname -a
> CYGWIN_NT-6.1-WOW64 Neptune 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
> Neptune:

Output of `id', please?  Is the administrators group in the group
list?  If so, problem solved.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

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