On Dec 23 12:10, Houder wrote:
> On 2015-12-23 11:50, Corinna Vinschen wrote:
> >On Dec 22 15:42, Houder wrote:
> >>The
> >>difference is that 'ls -l' on FC19 shows an additional plus sign.
> >
> >This is a problem in ls itself. The reason is that with the start of
> >reimplementing the ACL handli
On 2015-12-23 11:50, Corinna Vinschen wrote:
On Dec 22 15:42, Houder wrote:
On 2015-12-22 12:37, Houder wrote:
>On 2015-12-21 18:25, Corinna Vinschen wrote:
>>On Dec 21 17:30, Houder wrote:
>>>Hi Corinna,
>>>
>>>For next year ! (posted as a reminder) ... See below.
>>
>>Next year? Nope... s
On Dec 22 15:42, Houder wrote:
> On 2015-12-22 12:37, Houder wrote:
> >On 2015-12-21 18:25, Corinna Vinschen wrote:
> >>On Dec 21 17:30, Houder wrote:
> >>>Hi Corinna,
> >>>
> >>>For next year ! (posted as a reminder) ... See below.
> >>
> >>Next year? Nope... see below.
> >>
> >
> >Hi Corinna
On 2015-12-22 12:37, Houder wrote:
On 2015-12-21 18:25, Corinna Vinschen wrote:
On Dec 21 17:30, Houder wrote:
Hi Corinna,
For next year ! (posted as a reminder) ... See below.
Next year? Nope... see below.
Hi Corinna,
Thank you for all the hard work you do ...
As an encore (for th
On 2015-12-22 12:37, Houder wrote:
On 2015-12-21 18:25, Corinna Vinschen wrote:
On Dec 21 17:30, Houder wrote:
Hi Corinna,
For next year ! (posted as a reminder) ... See below.
Next year? Nope... see below.
Hi Corinna,
Thank you for all the hard work you do ...
As an encore (for th
On 2015-12-22 12:37, Houder wrote:
On 2015-12-21 18:25, Corinna Vinschen wrote:
On Dec 21 17:30, Houder wrote:
Hi Corinna,
For next year ! (posted as a reminder) ... See below.
Next year? Nope... see below.
Hi Corinna,
Thank you for all the hard work you do ...
As an encore (for th
On 2015-12-21 18:25, Corinna Vinschen wrote:
On Dec 21 17:30, Houder wrote:
Hi Corinna,
For next year ! (posted as a reminder) ... See below.
Next year? Nope... see below.
Hi Corinna,
Thank you for all the hard work you do ...
As an encore (for this year though ;-). See below (Cygwi
On Dec 21 17:30, Houder wrote:
> Hi Corinna,
>
> For next year ! (posted as a reminder) ... See below.
Next year? Nope... see below.
> Regards,
> Henri
>
> 64-%% uname -a
> CYGWIN_NT-6.1 Seven 2.4.0(0.292/5/3) 2015-12-21 13:10 x86_64 Cygwin
>
> 64-%% touch bar.txt
> 64-%% getfacl bar.txt
On Dec 21 14:11, Houder wrote:
> On 2015-12-21 13:46, Corinna Vinschen wrote:
> >On Dec 20 18:52, Houder wrote:
> >>Hi Corinna,
> >>
> >>According to acl(5), the mask entry (as reported by getacl) is
> >>"optional" if
> >>the
> >>acl contains no 'u:uid:perm' and/or 'g:gid:perm' entries (ace's) ...
On Dec 21 14:13, Thomas Wolff wrote:
> On 18.12.2015 20:38, EXT Corinna Vinschen wrote:
> >On Dec 18 18:11, Corinna Vinschen wrote:
> >>On Dec 18 17:14, Thomas Wolff wrote:
> >>>I wrote:
> ...
> After removing SYSTEM write permission with setfacl,
> it was effectively removed for SYSTEM
On 18.12.2015 20:38, EXT Corinna Vinschen wrote:
On Dec 18 18:11, Corinna Vinschen wrote:
On Dec 18 17:14, Thomas Wolff wrote:
I wrote:
...
After removing SYSTEM write permission with setfacl,
it was effectively removed for SYSTEM but the other groups got
write permission ADDED instead (as als
On 2015-12-21 13:46, Corinna Vinschen wrote:
On Dec 20 18:52, Houder wrote:
Hi Corinna,
According to acl(5), the mask entry (as reported by getacl) is
"optional" if
the
acl contains no 'u:uid:perm' and/or 'g:gid:perm' entries (ace's) ...
Ahem.
[...]
However, setfacl(1) and your setfacl also
On Dec 20 18:52, Houder wrote:
> Hi Corinna,
>
> According to acl(5), the mask entry (as reported by getacl) is "optional" if
> the
> acl contains no 'u:uid:perm' and/or 'g:gid:perm' entries (ace's) ... Ahem.
> [...]
> However, setfacl(1) and your setfacl also note, that the default behaviour
> of
On Dec 20 12:29, Houder wrote:
> Hi Corinna,
>
> Euh ... I do not pretend to be familiar (less understand) with the features
> that go into 2.4.0 (as I have no need for them) ...
>
> ... but, by just browsing the source code of setfacl and by just looking at
> the user interface of setfacl ... Se
On Dec 19 14:03, Houder wrote:
> Hi Corinna,
>
> setfacl(2.4.0) does not accept -x (-d is accepted).
>
> Looking at the source of setfacl.c, I believe a colon is missing after x in
> the opts string (const char *opts).
>
> Regards,
> Henri
>
> newlib-cygwin-2.4.0/gnewlib-cygwin-2.4.0/newlib-c
On Dec 18 18:11, Corinna Vinschen wrote:
> On Dec 18 17:14, Thomas Wolff wrote:
> > I wrote:
> > >...
> > >After removing SYSTEM write permission with setfacl,
> > >it was effectively removed for SYSTEM but the other groups got
> > >write permission ADDED instead (as also properly indicated by ls)
On Dec 18 17:14, Thomas Wolff wrote:
> I wrote:
> >...
> >After removing SYSTEM write permission with setfacl,
> >it was effectively removed for SYSTEM but the other groups got
> >write permission ADDED instead (as also properly indicated by ls) −
> >which is kind of the opposite of the intended op
I wrote:
...
After removing SYSTEM write permission with setfacl,
it was effectively removed for SYSTEM but the other groups got
write permission ADDED instead (as also properly indicated by ls) −
which is kind of the opposite of the intended operation.
cygwin-2.4.0-0.11, sorry
--
Problem repor
On Dec 18 16:29, Thomas Wolff wrote:
> For my Desktop folder (as logged below), SYSTEM had group write permission,
> other groups did not have write permissions (by mask).
> After removing SYSTEM write permission with setfacl,
> it was effectively removed for SYSTEM but the other groups got
> write
On Apr 8 16:40, Steven Penny wrote:
> On Wed, Apr 8, 2015 at 5:17 AM, Steven Penny wrote:
> > I upgraded to the new Cygwin today, why is this command producing different
> > permissions? Moreover how do I get it to produce sane results?
>
> I was able to use these command to produce sane results
On Wed, Apr 8, 2015 at 4:46 PM, Andrey Repin wrote:
> Cygwin is not Linux.
> And C:\ drive is not a part of Cygwin.
> If you really want to destroy your Windows installation, there's easier ways
> than meddling with setfacl on the root drive.
Thanks for the reply. However, did you have anything co
Greetings, Steven Penny!
>> I upgraded to the new Cygwin today, why is this command producing different
>> permissions? Moreover how do I get it to produce sane results?
> I was able to use these command to produce sane results
> $ cd /cygdrive/c
> $ touch bad.txt
> $ setfacl -k .
On Wed, Apr 8, 2015 at 5:17 AM, Steven Penny wrote:
> I upgraded to the new Cygwin today, why is this command producing different
> permissions? Moreover how do I get it to produce sane results?
I was able to use these command to produce sane results
$ cd /cygdrive/c
$ touch bad.txt
On 8. 4. 2015 12:17, Steven Penny wrote:
> Also I discovered this
>
> $ setfacl -b /cygdrive/c
>
> After that you get this
>
> C:\ is not accessible.
> Access is denied.
>
> Luckily this was in a virtual machine. Otherwise, can this be undone? This is
> very dangerous, and I feel it
On Feb 16 17:40, Houder wrote:
> > On Feb 16 14:53, Houder wrote:
> >> > Hi Corinna,
> >> >
> >> > Yes, sorry, setfacl again ...
> >> [snip]
> >>
> >> > RFC :-)
> >
> > Dumb bug in Cygwin. I found it and fixed it locally.
>
> Indeed? Did expect a deliberate different school of thoughts ... Appare
> On Feb 16 14:53, Houder wrote:
>> > Hi Corinna,
>> >
>> > Yes, sorry, setfacl again ...
>> [snip]
>>
>> > RFC :-)
>
> Dumb bug in Cygwin. I found it and fixed it locally.
Indeed? Did expect a deliberate different school of thoughts ... Apparently,
not.
[snip]
> Actually, I don't think I'm goi
On Feb 16 14:53, Houder wrote:
> > Hi Corinna,
> >
> > Yes, sorry, setfacl again ...
> [snip]
>
> > RFC :-)
Dumb bug in Cygwin. I found it and fixed it locally.
> Btw, my post is NOT a request for a snapshot at the end of the day, in which
> things have been fixed ... :-)
Heh, thanks :)
Actua
> Hi Corinna,
>
> Yes, sorry, setfacl again ...
[snip]
> RFC :-)
Btw, my post is NOT a request for a snapshot at the end of the day, in which
things have been fixed ... :-)
I wrote it up as a notice (or a request for an exchange of thoughts).
Henri
--
Problem reports: http://cygwin.com/
On Feb 13 00:19, Houder wrote:
> > On Feb 12 16:06, Houder wrote:
> >> Hi Corinna,
> >>
> >> Regression? setfacl -s used to accept multiple file arguments ... (yes, I
> >> am sure)
> >>
> >> @@ touch aap noot mies
> >> @@ ls -l aap noot mies
> >> -rw-r--r-- 1 Henri None 0 Feb 12 15:55 aap
> >> -rw
> On Feb 12 16:06, Houder wrote:
>> Hi Corinna,
>>
>> Regression? setfacl -s used to accept multiple file arguments ... (yes, I am
>> sure)
>>
>> @@ touch aap noot mies
>> @@ ls -l aap noot mies
>> -rw-r--r-- 1 Henri None 0 Feb 12 15:55 aap
>> -rw-r--r-- 1 Henri None 0 Feb 12 15:55 mies
>> -rw-r--
> On Feb 12 19:29, Houder wrote:
>> On Thu, 12 Feb 2015 19:00:41, Corinna wrote:
>>
>> > Btw., it's really not necessary to address me directly in the subject of
>> > a mail to this list. I am reading this list regulary and I'm not
>> > ignoring reports which look like a bug in Cygwin and least of
On Feb 12 19:29, Houder wrote:
> On Thu, 12 Feb 2015 19:00:41, Corinna wrote:
>
> > Btw., it's really not necessary to address me directly in the subject of
> > a mail to this list. I am reading this list regulary and I'm not
> > ignoring reports which look like a bug in Cygwin and least of all t
On Feb 12 16:06, Houder wrote:
> Hi Corinna,
>
> Regression? setfacl -s used to accept multiple file arguments ... (yes, I am
> sure)
>
> @@ touch aap noot mies
> @@ ls -l aap noot mies
> -rw-r--r-- 1 Henri None 0 Feb 12 15:55 aap
> -rw-r--r-- 1 Henri None 0 Feb 12 15:55 mies
> -rw-r--r-- 1 Henr
On Feb 9 16:05, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> The setfacl man page does not document the new -b and -k flags.
The man pages are part of the cygwin-doc package which hasn't been
updated for a while, because it's ORPHANED.
If you're interested to pick up this package as maintainer, it
On Wed, Mar 10, 2010 at 10:42:41PM +, Francis Litterio wrote:
>DePriest, Jason R. writes:
>> According to http://cygwin.com/cygwin-ug-net/using.html#using-pathnames,
>> Cygwin supports both Win32 and POSIX file paths and they are
>> translated internally on-the-fly as needed.
>
>Indeed. Cygwin
Eric Blake redhat.com> writes:
> Yes, this is on purpose. Use of a drive letter says that you DON'T want
> POSIX path processing, therefore, you are also giving up ACL processing.
> Moral of the story - don't expect drive letters to do what you want.
> Use POSIX paths.
Thanks, Eric. I just wan
On 03/10/2010 03:42 PM, Francis Litterio wrote:
> This gets stranger. Watch this:
>
> $ /bin/ls -l /cygdrive/c/temp/xyz
> -rwx--+ 1 littef Domain Users 6714 Mar 1 15:07 /cygdrive/c/temp/xyz
> $ /bin/ls -l c:/temp/xyz
> -rw-r--r-- 1 littef Domain Users 6714 Mar 1 15:07 c:/temp/xyz
>
DePriest, Jason R. gmail.com> writes:
> According to http://cygwin.com/cygwin-ug-net/using.html#using-pathnames,
> Cygwin supports both Win32 and POSIX file paths and they are
> translated internally on-the-fly as needed.
Indeed. Cygwin has allowed pathnames to start with drive letters for as l
> But it used to work. I noticed this after updating to the latest release.
>
> If the drive-letter form of the pathname is not acceptable to the tool, it
> should complain, but (like most Cygwin utilities) it probably doesn't care
> about
> the syntax of the pathname, as long as open(2) accepts
DePriest, Jason R. gmail.com> writes:
> On Wed, Mar 10, 2010 at 3:43 PM, Francis Litterio wrote:
> > I notice that setfacl does not change the ACLs of a file when given a
> > pathname starting with a drive letter (e.g., c:/temp/zzz), but it will work
> > when given a UNIX-style pathname (e.g., /c
On Wed, Mar 10, 2010 at 3:43 PM, Francis Litterio <> wrote:
> I notice that setfacl does not change the ACLs of a file when given a pathname
> starting with a drive letter (e.g., c:/temp/zzz), but it will work when given
> a
> UNIX-style pathname (e.g., /cygdrive/c/temp/zzz). Example below. Is t
On Feb 10 17:51, Linda Walsh wrote:
> Would it be possible to replace the setfacl in cygwin with the one
> available in linux -- it's alot more powerful:
Feel free to port the tool and become Cygwin maintaner for it.
Corinna
--
Corinna Vinschen Please, send mails regarding Cyg
On May 22 18:36, Bruno Haible wrote:
> Corinna Vinschen wrote:
> > > What error code do you want? EINVAL?
>
> EINVAL sounds right, yes. The Solaris manual page [1] also mentions it:
>
> "EINVAL
> ... the cmd argument is SETACL or ACE_SETACL and the ACL specified in
> aclbufp is not val
On Thu, May 22, 2008 at 12:36 PM, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Corinna Vinschen wrote:
>> > What error code do you want? EINVAL?
>
> EINVAL sounds right, yes. The Solaris manual page [1] also mentions it:
>
> "EINVAL
>... the cmd argument is SETACL or ACE_SETACL and the ACL speci
Corinna Vinschen wrote:
> > What error code do you want? EINVAL?
EINVAL sounds right, yes. The Solaris manual page [1] also mentions it:
"EINVAL
... the cmd argument is SETACL or ACE_SETACL and the ACL specified in
aclbufp is not valid."
> I applied a patch to CVS so this situation wi
On May 22 14:34, Corinna Vinschen wrote:
> On May 22 05:47, Eric Blake wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > According to Bruno Haible on 5/21/2008 5:05 PM:
> > | Hi Eric,
> > |
> > | I'm looking at ACL support for gnulib. Can you reproduce this with a
> > | recent Cy
On May 22 05:47, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Bruno Haible on 5/21/2008 5:05 PM:
> | Hi Eric,
> |
> | I'm looking at ACL support for gnulib. Can you reproduce this with a
> | recent Cygwin? With a two-year-old Cygwin I got this:
>
> I reproduc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/21/2008 5:05 PM:
| Hi Eric,
|
| I'm looking at ACL support for gnulib. Can you reproduce this with a
| recent Cygwin? With a two-year-old Cygwin I got this:
I reproduced the same symptoms with cygwin 1.5.25-11.
|
| $ t
I use it daily.
A tip to fix or remove fACL's: first fix the directory, then the file.
2007/5/11, John J. Culkin <[EMAIL PROTECTED]>:
Has anyone tried using setfacl so set ACL's on files?
John J. Culkin wrote:
> I tried putting UMask commands in both places and neither seem to have
> any effe
On Jan 7 14:18, Tom Rodman wrote:
> On Sun 1/7/07 12:23 +0100 cygwin@cygwin.com wrote:
> > On Jan 5 13:34, Tom Rodman wrote:
> > > setfacl -m u:jdoe:rwx foo
> > >
> > > Above command returns 0 but jdoe can not write. The cause appears to
> > > be that the windows RO file attribute is not unse
On Sun 1/7/07 12:23 +0100 cygwin@cygwin.com wrote:
> On Jan 5 13:34, Tom Rodman wrote:
> > Admittedly, this may be going "outside the cygwin perms model" a bit:
> >
> > In the below test case file 'foo' has it's RO file attribute set, then has
> > it's owner changed to someone other than the curr
On Jan 5 13:34, Tom Rodman wrote:
> Admittedly, this may be going "outside the cygwin perms model" a bit:
>
> In the below test case file 'foo' has it's RO file attribute set, then has
> it's owner changed to someone other than the current user, has the posix
> group set to None, the DACL protect
On Apr 10 20:10, Dmitry Bely wrote:
> C:\Work\test-facl>setfacl -m d:u::rwx,d:g::rwx,d:m:rwx,d:o:rwx .
>
> C:\Work\test-facl>getfacl .
> # file: .
> # owner: Administrators
> # group: None
> user::rwx
> group::rwx
> mask:rwx
> other:---
> default:user::rwx
> default:group::rwx
> default:other:rw
53 matches
Mail list logo
