Re: rename a user using setfacl -- possible? how?

Greetings, L A Walsh! > On 2019/07/06 10:01, Brian Inglis wrote: >> On 2019-07-06 10:01, Andrey Repin wrote: >> > It should, but I strongly suggest to avoid using it outside Cygwin > directory > tree to maintain maximum interoperability with Windows programs. > >>

Re: rename a user using setfacl -- possible? how?

On 2019/07/06 10:01, Brian Inglis wrote: > On 2019-07-06 10:01, Andrey Repin wrote: > >>> It should, but I strongly suggest to avoid using it outside Cygwin directory tree to maintain maximum interoperability with Windows programs. >>> No problem. my cygwin

Re: rename a user using setfacl -- possible? how?

L A Walsh writes: > Have an acl on a file 'testfile' that appears to include a userid > with a GUID corresponding to some older value for the local system. That problem is surprisingly hard to tackle (even though it is quite common when you need to move data disks between machines) unless you want

Re: rename a user using setfacl -- possible? how?

On 2019-07-06 10:01, Andrey Repin wrote: >> On 2019/07/06 02:06, Andrey Repin wrote: I guess I don't know how to modify an entry to either 1-rename it, or 2 add the new entry. >>> You don't. >>> If you want to change name for display purposes, look into nsswitch.conf and >>> associated do

Re: rename a user using setfacl -- possible? how?

Greetings, L A Walsh! > I don't think I explained things clearly. > On 2019/07/06 02:06, Andrey Repin wrote: >>> I guess I don't know how to modify an entry to either 1-rename it, or >>> 2 add the new entry. >> >> You don't. >> If you want to change name for display purposes, look into nsswitch

Re: rename a user using setfacl -- possible? how?

s to manipulate the NTFS ACLs I'd be inclined to look at native tools, probably using a Powershell script if you need to automate it. If you use setfacl on paths outside your 'Cygwin domain' it's going to mess up the more normal Windows/NTFS ACL usage especially the inheritanc

Re: rename a user using setfacl -- possible? how?

I don't think I explained things clearly. On 2019/07/06 02:06, Andrey Repin wrote: >> I guess I don't know how to modify an entry to either 1-rename it, or >> 2 add the new entry. > > You don't. > If you want to change name for display purposes, look into nsswitch.conf and > associated documenta

Re: rename a user using setfacl -- possible? how?

its own users/groups/ids/guids. It maps Windows permissions to some POSIX equivalent, but internally it still using native permissions. > I tried setfacl -x group:oldname:rwx -m group:curname:rwx but got: > setfacl: illegal acl entries Seems like it did not recognize the group name. At least

Re: rename a user using setfacl -- possible? how?

oldname' (where current name, is say, 'curname'). > I guess I don't know how to modify an entry to either 1-rename it, or > 2 add the new entry. > I tried > setfacl -x group:oldname:rwx -m group:curname:rwx but got: > setfacl: illegal acl entries > will setfacl

rename a user using setfacl -- possible? how?

x27;). I guess I don't know how to modify an entry to either 1-rename it, or 2 add the new entry. I tried setfacl -x group:oldname:rwx -m group:curname:rwx but got: setfacl: illegal acl entries will setfacl not work for this task? How do you add a new user to the access list -- obviously

Re: setfacl(2.4.0.15): for next year !!!!!

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

Re: setfacl(2.4.0.15): for next year !!!!!

... 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 (Cygwin-2.4.0-0.16). >< 16 [snip] >64-%% setfacl -m m:rwx bar.txt >64-%%

Re: setfacl(2.4.0.15): for next year !!!!!

> >> > >>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 (Cygwin-2.4.0-0.16). > >< 16 > [snip] > >

Re: setfacl(2.4.0.15): for next year !!!!!

this year though ;-). See below (Cygwin-2.4.0-0.16). < 16 [snip] 64-%% setfacl -m m:rwx bar.txt 64-%% getfacl bar.txt # file: bar.txt # owner: Henri # group: None user::rw- group::r-- mask:rwx < yes, as requested by me, but ... other:r-- 64-%% ls -l bar.txt -rw-rwxr-- 1 Henri None

Re: setfacl(2.4.0.15): for next year !!!!! continued (2)

this year though ;-). See below (Cygwin-2.4.0-0.16). < 16 [snip] 64-%% setfacl -m m:rwx bar.txt 64-%% getfacl bar.txt # file: bar.txt # owner: Henri # group: None user::rw- group::r-- mask:rwx < yes, as requested by me, but ... other:r-- 64-%% ls -l bar.txt -rw-rwxr-- 1 Henri None

Re: setfacl(2.4.0.15): for next year !!!!! continued

this year though ;-). See below (Cygwin-2.4.0-0.16). < 16 [snip] 64-%% setfacl -m m:rwx bar.txt 64-%% getfacl bar.txt # file: bar.txt # owner: Henri # group: None user::rw- group::r-- mask:rwx < yes, as requested by me, but ... other:r-- 64-%% ls -l bar.txt -rw-rwxr-- 1 Henri None

Re: setfacl(2.4.0.15): for next year !!!!!

(Cygwin-2.4.0-0.16). < 16 Regards, Henri - 64-%% uname -a CYGWIN_NT-6.1 Seven 2.4.0(0.292/5/3) 2015-12-21 18:20 x86_64 Cygwin 64-%% touch bar.txt 64-%% getfacl bar.txt # file: bar.txt # owner: Henri # group: None user::rw- group::r-- other:r-- 64-%% setfacl -m m:rwx bar.txt 64-%% getf

Re: setfacl(2.4.0.15): for next year !!!!!

ar.txt > 64-%% getfacl bar.txt > # file: bar.txt > # owner: Henri > # group: None > user::rw- > group::r-- > other:r-- > > 64-%% setfacl -m g:None:rw- -x g:None: bar.txt # add and delete ... > 64-%% getfacl bar.txt > # file: bar.txt > # owner: Henri > # group:

setfacl(2.4.0.15): for next year !!!!!

-%% setfacl -m g:None:rw- -x g:None: bar.txt # add and delete ... 64-%% getfacl bar.txt # file: bar.txt # owner: Henri # group: None user::rw- group::r-- group:None:rwx < surprise! (this one, I did not even specify!) mask:rwx other:r-- 64-%% ls -l bar.txt -rw-rwxr--+ 1 Henri None 0 Dec 21 17

Re: setfacl(2.4.0.14): recalculation of the ACL mask entry

; >>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 > >>setfacl is to recalculate the mas

Re: setfacl to remove a permission implicit adds another

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 p

Re: setfacl to remove a permission implicit adds another

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

Re: setfacl(2.4.0.14): recalculation of the ACL mask entry

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. [...] H

Re: setfacl(2.4.0.14): recalculation of the ACL mask entry

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

setfacl(2.4.0.14): recalculation of the ACL mask entry

ains no entries of ACL_USER or ACL_GROUP tag types, the ACL_MASK entry is optional. However, setfacl(1) and your setfacl also note, that the default behaviour of setfacl is to recalculate the mask entry ... %% setfacl -h Usage: setfacl [-n] {-f ACL_FILE | -s acl_entries} FILE...

Re: setfacl(2.4.0.13): options --no-mask and --mask

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

setfacl(2.4.0.13): options --no-mask and --mask

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 ... See below. Regards, Henri Source code

Re: setfacl(2.4.0): colon missing after x (opts string)?

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-

setfacl(2.4.0): colon missing after x (opts string)?

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-cygwin/winsup/utils/setfacl.c shows: struct

Re: setfacl to remove a permission implicit adds another

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 AD

Re: setfacl to remove a permission implicit adds another

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 kin

Re: setfacl to remove a permission implicit adds another

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

Re: setfacl to remove a permission implicit adds another

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 othe

setfacl to remove a permission implicit adds another

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 permission ADDED instead (as also properly

Re: setfacl can kill a drive

produce sane results > > $ cd /cygdrive/c > > $ touch bad.txt > > $ setfacl -k . > > $ touch good.txt > > $ ls -l *.txt > -rw-rwxr--+ 1 John None 0 Apr 8 02:16 bad.txt > -rw-r--r-- 1 John None 0 Apr 8 02:16 good.txt > &g

Re: setfacl can kill a drive

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

Re: setfacl can kill a drive

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.tx

Re: setfacl can kill a drive

ad.txt $ setfacl -k . $ touch good.txt $ ls -l *.txt -rw-rwxr--+ 1 John None 0 Apr 8 02:16 bad.txt -rw-r--r-- 1 John None 0 Apr 8 02:16 good.txt I feel that the default permissions are wrong here. On linux when you create a new file with touch, it does not have exec

Re: setfacl can kill a drive

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 i

setfacl can kill a drive

/alpha.txt -rw-r--r-- 1 Steven None 0 Apr 8 05:06 /home/Steven/alpha.txt 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

Re: setfacl: root of all evil?

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

Re: setfacl: root of all evil?

> 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 ..

Re: setfacl: root of all evil?

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

Re: setfacl: root of all evil?

> 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:

setfacl: root of all evil?

Hi Corinna, Yes, sorry, setfacl again ... Now, I am NOT an expert on Windows (I do not want to be), and I realize, that I am in the company of experts on Windows (on Windows ACL) here, so it is inevitable, that I will be out of my league below, and speak "errorneously" about W

Re: setfacl -s acl_entries file file ... now fails

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 > >> @

Re: setfacl -s acl_entries file file ... now fails

> 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 >

Re: setfacl -s acl_entries file file ... now fails ... *******? (censured)

> 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

Re: setfacl -s acl_entries file file ... now fails ... *******? (censured)

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

setfacl -s acl_entries file file ... now fails ... *******? (censured)

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 those > with testcases. In fact, I'd pref

Re: setfacl -s acl_entries file file ... now fails

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 1

setfacl -s acl_entries file file ... now fails ... Corinna?

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 Henri None 0 Feb 12 15:55 noot @@ setfacl -s u::rwx,g

Re: setfacl man page

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 pac

setfacl man page

The setfacl man page does not document the new -b and -k flags. However, they are documented by setfacl --help . - Barry Disclaimer: Statements made herein are not made on behalf of NIAID. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq

Re: Syntax error in setfacl man page

On Apr 12 19:27, Fran wrote: > I wrote: > > > Sometime in the last few months, setfacl stopped accepting two colons (::) > > after the keyword "other", as in this example: > > > > $ setfacl -s user::rw-,group::r--,other::r-- filename > > setfacl

Re: Syntax error in setfacl man page

I wrote: > Sometime in the last few months, setfacl stopped accepting two colons (::) > after the keyword "other", as in this example: > > $ setfacl -s user::rw-,group::r--,other::r-- filename > setfacl: illegal acl entries > > But the setfacl(1) man pag

Syntax error in setfacl man page

Sometime in the last few months, setfacl stopped accepting two colons (::) after the keyword "other", as in this example: $ setfacl -s user::rw-,group::r--,other::r-- filename setfacl: illegal acl entries But the setfacl(1) man page continues to show the invalid syntax: o[ther]:

Re: setfacl fails to replace ACLs when given a pathname starting with a drive letter

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

Re: setfacl fails to replace ACLs when given a pathname starting with a drive letter

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

Re: setfacl fails to replace ACLs when given a pathname starting with a drive letter

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 >

Re: setfacl fails to replace ACLs when given a pathname starting with a drive letter

appear as > subdirectories (for example, you might buy a new disk and make it be > the /disk2 directory)." Yes, but I'm not sure how that's relevant to the behavior of setfacl when given a pathname starting with a drive letter. > By the way, when you said "updating to

Re: setfacl fails to replace ACLs when given a pathname starting with a drive letter

> 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

Re: setfacl fails to replace ACLs when given a pathname starting with a drive letter

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

Re: setfacl fails to replace ACLs when given a pathname starting with a drive letter

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).  

setfacl fails to replace ACLs when given a pathname starting with a drive letter

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 this a known problem? -- Fran $ /bin/ls -l zzz -rw-r--r--+ 1 littef

Re: setfacl -- upgrade? and/or add 'chacl'?

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 mail

setfacl -- upgrade? and/or add 'chacl'?

Would it be possible to replace the setfacl in cygwin with the one available in linux -- it's alot more powerful: NAME setfacl - set file access control lists SYNOPSIS setfacl [-bkndRLPvh] [{-m|-x} acl_spec] [{-M|-X} acl_file] file ... setfacl --restore=file --- Notably i

Re: wamp cygwin php. Files with acl, setfacl, issue

a php 'is_file()' returns false on a file that most > certainly exists. Figuring out what was going on was source of much > headache. > > I'm sure I am not the first person to have this problem, but I'm having > trouble finding info, I've been reading about

Re: Cannot change file permission with either chmod or setfacl

Brian Dessent wrote: Laurent Monnoye wrote: $ chmod 600 foo $ ls -l foo -rw-r--r-- 0 xotrader01 Users 4 Sep 5 18:05 foo You've left out the most relevant detail: what type of filesystem does foo reside on? NTFS, FAT, NFS, Samba? Yep. See the FAQ entry:

Re: Cannot change file permission with either chmod or setfacl

Laurent Monnoye wrote: > $ chmod 600 foo > > $ ls -l foo > -rw-r--r-- 0 xotrader01 Users 4 Sep 5 18:05 foo You've left out the most relevant detail: what type of filesystem does foo reside on? NTFS, FAT, NFS, Samba? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Pro

Cannot change file permission with either chmod or setfacl

Hello, I'm trying to change the permission of a file from 644 to 600. I've tried chmod and setfacl without success. Can someone please help me with this? Details follow: Platform is XP. $ uname -srv CYGWIN_NT-5.1 1.5.25(0.156/4/2) 2008-06-12 19:34 $ ls -l foo -rw-r--r-- 0 xotrader

Re: setfacl on Cygwin

pecified in > aclbufp is not valid." > > > I applied a patch to CVS so this situation will return an "Invalid argument" > > error message now. > > Thanks. Will the setfacl program then exit with non-zero exit code (since it > could not set the requested A

Re: setfacl on Cygwin

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

Re: setfacl on Cygwin

S so this situation will return an "Invalid argument" > error message now. Thanks. Will the setfacl program then exit with non-zero exit code (since it could not set the requested ACL)? Bruno [1] http://docs.sun.com/app/docs/doc/816-5167/acl-2?l=en&a=view -- Unsubscribe info:

Re: setfacl on Cygwin

> > | # owner: haible > > | # group: None > > | user::rw- > > | group::r-- > > | mask:rwx > > | other:r-- > > | > > | $ setfacl -m user:4:--x foo > > | setfacl: No error > > | > > | $ echo $? > > | 0 > > | > > | $ getfacl foo >

Re: setfacl on Cygwin

-old Cygwin I got this: > > I reproduced the same symptoms with cygwin 1.5.25-11. > > | > | $ touch foo > | > | $ getfacl foo > | # file: foo > | # owner: haible > | # group: None > | user::rw- > | group::r-- > | mask:rwx > | other:r-- > | > | $ setfacl -m u

Re: setfacl on Cygwin

25-11. | | $ touch foo | | $ getfacl foo | # file: foo | # owner: haible | # group: None | user::rw- | group::r-- | mask:rwx | other:r-- | | $ setfacl -m user:4:--x foo | setfacl: No error | | $ echo $? | 0 | | $ getfacl foo | # file: foo | # owner: haible | # group: None | user::rw- | group::r-- | mas

Re: setfacl

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

setfacl

Has anyone tried using setfacl so set ACL's on files? -- John C. John J. Culkin wrote: I tried putting UMask commands in both places and neither seem to have any effect on files created by sftp -- John C. -- John J. Culkin Systems Administrator [EMAIL PROTECTED]

Re: `setfacl -m u:jdoe:rwx foo` returns 0, but file not writable by jdoe??

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 > > >

Re: `setfacl -m u:jdoe:rwx foo` returns 0, but file not writable by jdoe??

t; > it's owner changed to someone other than the current user, has the posix > > group set to None, the DACL protected, and all aces removed from the DACL. > > > > Next step is to run this (assumes we are user 'jdoe' [an administrator]): > > > > setf

Re: `setfacl -m u:jdoe:rwx foo` returns 0, but file not writable by jdoe??

as the posix > group set to None, the DACL protected, and all aces removed from the DACL. > > Next step is to run this (assumes we are user 'jdoe' [an administrator]): > > setfacl -m u:jdoe:rwx foo > > Above command returns 0 but jdoe can not write. The cause appears t

`setfacl -m u:jdoe:rwx foo` returns 0, but file not writable by jdoe??

all aces removed from the DACL. Next step is to run this (assumes we are user 'jdoe' [an administrator]): 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 unset by setfacl. The example below uses &

Re: setfacl bug?

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:--- >

setfacl bug?

Let's consider the following scenario: [--- cut ---] C:\Work\test-facl>setfacl -s u::rwx,g::rwx,m:rwx,o:rwx . C:\Work\test-facl>getfacl . # file: . # owner: Administrators # group: None user::rwx group::rwx mask:rwx other:rwx C:\Work\test-facl>setfacl -m d:u::rwx,d:g::rwx,d

Re: Problem with SETFACL and shortcuts?

On Fri, 26 Sep 2003 16:30:14 +0200, "Corinna Vinschen" <[EMAIL PROTECTED]> said: > Chuck, would it make sense to change the symlink to an absolute one? Probably. I'll put it on my todo list...but I'm a bit swamped right now. I won't be updating anything for at least a week. -- Chuck -- Charl

RE: Problem with SETFACL and shortcuts?

On Sat, 27 Sep 2003, Harre Mark VIE wrote: > [snip] > If I may ask another question regarding setfacl. > I would like to use setfacl on all subdirs but unlike chmod it doesn't > have a recursive option (unless I missed it somewhere?) so I use the > following bash sc

RE: Problem with SETFACL and shortcuts?

Thx Corinna That explains it better for me - I was a little confused by the relationship between windows shortcuts and *nix symlinks. If I may ask another question regarding setfacl. I would like to use setfacl on all subdirs but unlike chmod it doesn't have a recursive option (unless I m

Re: Problem with SETFACL and shortcuts?

On Fri, Sep 26, 2003 at 04:06:32PM +0200, Harre Mark VIE wrote: > Hi, > > I was just working on a script to set dafault permissions and noticed > something interesting. I use the find command to get the file name of > all files/directories and then reset the permissions usiong

Problem with SETFACL and shortcuts?

Hi, I was just working on a script to set dafault permissions and noticed something interesting. I use the find command to get the file name of all files/directories and then reset the permissions usiong setfacl. This works fine except on a couple of files. I get the same error from a bash shell