umask not working?

umask not working?

[David Allsopp]

Is this expected behaviour:

OPAM+DRA@OPAM ~
$ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ;
touch /tmp/bar/foo ; ls -l /tmp/bar/foo
CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
0022
-rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
-rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo

Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not sure
what to look at on my system to diagnose what I may have inadvertently
tweaked. The directory itself is:

drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar

Thanks!


David


--
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: EXTERNAL: umask not working?

[Wells, Roger K.]

On 03/19/2018 08:49 AM, David Allsopp wrote:
> Is this expected behaviour:
>
> OPAM+DRA@OPAM ~
> $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ;
> touch /tmp/bar/foo ; ls -l /tmp/bar/foo
> CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
> 0022
> -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
> -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo
>
> Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not sure
> what to look at on my system to diagnose what I may have inadvertently
> tweaked. The directory itself is:
>
> drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar
>
> Thanks!
>
>
> David
>
>
> --
> 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
>
>
FWIW
$ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ; 
touch /tmp/bar/foo ; ls -l /tmp/bar/foo
CYGWIN_NT-10.0 rwells-x240 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin
0022
-rw-r--r-- 1 roger None 0 Mar 19 09:29 /tmp/foo
mkdir: created directory '/tmp/bar'
-rw-r--r-- 1 roger None 0 Mar 19 09:29 /tmp/bar/foo

HTH

-- 

Roger Wells, P.E.
leidos
221 Third St
Newport, RI 02840
401-847-4210 (voice)
401-849-1585 (fax)
roger.k.wells@leidos.com


--
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: umask not working?

[Andrey Repin]

Greetings, David Allsopp!

> Is this expected behaviour:

> OPAM+DRA@OPAM ~
> $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ;
> touch /tmp/bar/foo ; ls -l /tmp/bar/foo
> CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
> 0022
> -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
> -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo

> Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not sure
> what to look at on my system to diagnose what I may have inadvertently
> tweaked. The directory itself is:

> drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar

Let me guess, /tmp usertemp ?

You have extended ACL on the object. And overall, umask is not a good idea in
Windows.


-- 
With best regards,
Andrey Repin
Monday, March 19, 2018 20:06:19

Sorry for my terrible english...


--
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: umask not working?

[Ken Brown]

On 3/19/2018 8:48 AM, David Allsopp wrote:
> Is this expected behaviour:
> 
> OPAM+DRA@OPAM ~
> $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar ;
> touch /tmp/bar/foo ; ls -l /tmp/bar/foo
> CYGWIN_NT-6.1-WOW OPAM 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
> 0022
> -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
> -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo
> 
> Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not sure
> what to look at on my system to diagnose what I may have inadvertently
> tweaked. The directory itself is:
> 
> drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar

See if this helps:

   https://cygwin.com/faq/faq.html#faq.using.same-with-permissions

Ken

--
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: umask not working?

[David Allsopp]

Andrey Repin wrote:
> Greetings, David Allsopp!
> 
> > Is this expected behaviour:
> 
> > OPAM+DRA@OPAM ~
> > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar
> > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM
> > 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
> > 0022
> > -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
> > -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo
> 
> > Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not
> > sure what to look at on my system to diagnose what I may have
> > inadvertently tweaked. The directory itself is:
> 
> > drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar
> 
> Let me guess, /tmp usertemp ?

No - it's default mounts, so /tmp = C:\cygwin\tmp, to which my (non-administrative) user has write access. 

> You have extended ACL on the object. And overall, umask is not a good
> idea in Windows.

"umask is not a good idea in Windows" - where's that come from? (In the actual scenario where I'm being bitten by this, it's because a git checkout is altering files which were 644 to be 664, so whether it's precisely umask or not, the *change* of permissions is the problem).


David


--
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: umask not working?

[David Allsopp]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2209 bytes --]

Ken Brown
> On 3/19/2018 8:48 AM, David Allsopp wrote:
> > Is this expected behaviour:
> >
> > OPAM+DRA@OPAM ~
> > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar
> > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM
> > 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
> > 0022
> > -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
> > -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo
> >
> > Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not
> > sure what to look at on my system to diagnose what I may have
> > inadvertently tweaked. The directory itself is:
> >
> > drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar
> 
> See if this helps:
> 
>    https://cygwin.com/faq/faq.html#faq.using.same-with-permissions

Thanks for the pointer. I wonder from it if this could be to do with the Cygwin installation being old (but upgraded). I tried on the same machine creating another installation to C:\cygwin2 (which behaves as Roger Wells noted) and then ran getfacl /tmp on each:

Old installation:

# file: /tmp
# owner: OPAM+DRA-Admin
# group: OPAM+None
user::rwx
user:OPAM+DRA:rwx
group::r-x
mask:rwx
other:r-x
default:user::rwx
default:user:OPAM+DRA:rwx
default:group::r-x
default:mask:rwx
default:other:r-x

Fresh installation:

# file: /tmp
# owner: OPAM+DRA-Admin
# group: OPAM+None
# flags: --t
user::rwx
group::rwx
other:rwx
default:user::rwx
default:group::r-x
default:other:r-x

I expect that the extra OPAM+DRA:rwx on the old installation was manually added by me, years ago. What are the "mask" entries all about?

The default:mask entry seems to be the crucial one, as if I do setfacl default:mask:rwx /tmp on the fresh installation, then I get the same behaviour as on the old installation.

However, I'm struggling to find references for either what these mask entries are, or how they ever appeared?

Thanks!


David 

\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: umask not working?

[Andrey Repin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1834 bytes --]

Greetings, David Allsopp!

> Andrey Repin wrote:
>> Greetings, David Allsopp!
>> 
>> > Is this expected behaviour:
>> 
>> > OPAM+DRA@OPAM ~
>> > $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar
>> > ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM
>> > 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
>> > 0022
>> > -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
>> > -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo
>> 
>> > Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not
>> > sure what to look at on my system to diagnose what I may have
>> > inadvertently tweaked. The directory itself is:
>> 
>> > drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar
>> 
>> Let me guess, /tmp usertemp ?

> No - it's default mounts, so /tmp = C:\cygwin\tmp, to which my
> (non-administrative) user has write access. 

>> You have extended ACL on the object. And overall, umask is not a good
>> idea in Windows.

> "umask is not a good idea in Windows" - where's that come from?

From knowledge and experience.
umask is strictly simple POSIX modes concept. In the ACL environment it is
anything from inappropriate to disastrous, but never useful.

> (In the actual scenario where I'm being bitten by this, it's because a git
> checkout is altering files which were 644 to be 664, so whether it's
> precisely umask or not, the *change* of permissions is the problem).

Use setfacl.


-- 
With best regards,
Andrey Repin
Wednesday, March 21, 2018 15:32:21

Sorry for my terrible english...\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: umask not working?

[Ken Brown]

On 3/21/2018 6:36 AM, David Allsopp wrote:
> Ken Brown
>> On 3/19/2018 8:48 AM, David Allsopp wrote:
>>> Is this expected behaviour:
>>>
>>> OPAM+DRA@OPAM ~
>>> $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir /tmp/bar
>>> ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW OPAM
>>> 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
>>> 0022
>>> -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
>>> -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo
>>>
>>> Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm not
>>> sure what to look at on my system to diagnose what I may have
>>> inadvertently tweaked. The directory itself is:
>>>
>>> drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar
>>
>> See if this helps:
>>
>>     https://cygwin.com/faq/faq.html#faq.using.same-with-permissions
> 
> Thanks for the pointer. I wonder from it if this could be to do with the Cygwin installation being old (but upgraded). I tried on the same machine creating another installation to C:\cygwin2 (which behaves as Roger Wells noted) and then ran getfacl /tmp on each:
> 
> Old installation:
> 
> # file: /tmp
> # owner: OPAM+DRA-Admin
> # group: OPAM+None
> user::rwx
> user:OPAM+DRA:rwx
> group::r-x
> mask:rwx
> other:r-x
> default:user::rwx
> default:user:OPAM+DRA:rwx
> default:group::r-x
> default:mask:rwx
> default:other:r-x
> 
> Fresh installation:
> 
> # file: /tmp
> # owner: OPAM+DRA-Admin
> # group: OPAM+None
> # flags: --t
> user::rwx
> group::rwx
> other:rwx
> default:user::rwx
> default:group::r-x
> default:other:r-x
> 
> I expect that the extra OPAM+DRA:rwx on the old installation was manually added by me, years ago. What are the "mask" entries all about?
> 
> The default:mask entry seems to be the crucial one, as if I do setfacl default:mask:rwx /tmp on the fresh installation, then I get the same behaviour as on the old installation.
> 
> However, I'm struggling to find references for either what these mask entries are, or how they ever appeared?

If you search the web for "Posix acl mask" you'll find lots of 
information.  Here's one that seems pretty good:

   https://cs.unc.edu/help-article/posix-acls-in-linux/

Ken


--
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: git checkout altering mode of file [WAS: umask not working?]

[cyg Simple]

On 3/21/2018 6:27 AM, David Allsopp wrote:
> 
> "umask is not a good idea in Windows" - where's that come from? (In the actual scenario where I'm being bitten by this, it's because a git checkout is altering files which were 644 to be 664, so whether it's precisely umask or not, the *change* of permissions is the problem).
> 

Git will also store the mode of the file.  Are you sure the file stored
within git doesn't have the 664 mode?  The other problems are mixing the
various git operators with Cygwin git.  For instance the embedded git of
Netbeans doesn't cooperate well with Cygwin git because of subtle
differences in the native versus Cygwin.

-- 
cyg Simple

--
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: umask not working?

[David Allsopp]

Ken Brown wrote:
> On 3/21/2018 6:36 AM, David Allsopp wrote:
> > Ken Brown
> >> On 3/19/2018 8:48 AM, David Allsopp wrote:
> >>> Is this expected behaviour:
> >>>
> >>> OPAM+DRA@OPAM ~
> >>> $ uname -a ; umask ; touch /tmp/foo ; ls -l /tmp/foo ; mkdir
> >>> /tmp/bar ; touch /tmp/bar/foo ; ls -l /tmp/bar/foo CYGWIN_NT-6.1-WOW
> >>> OPAM
> >>> 2.10.0(0.325/5/3) 2018-02-02 15:21 i686 Cygwin
> >>> 0022
> >>> -rw-r--r-- 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/foo
> >>> -rw-rw-r--+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar/foo
> >>>
> >>> Why does the file /tmp/bar/foo get g+w when /tmp/foo doesn't - I'm
> >>> not sure what to look at on my system to diagnose what I may have
> >>> inadvertently tweaked. The directory itself is:
> >>>
> >>> drwxr-xr-x+ 1 OPAM+DRA OPAM+None 0 Mar 19 13:44 /tmp/bar
> >>
> >> See if this helps:
> >>
> >>     https://cygwin.com/faq/faq.html#faq.using.same-with-permissions
> >
> > Thanks for the pointer. I wonder from it if this could be to do with
> the Cygwin installation being old (but upgraded). I tried on the same
> machine creating another installation to C:\cygwin2 (which behaves as
> Roger Wells noted) and then ran getfacl /tmp on each:
> >
> > Old installation:
> >
> > # file: /tmp
> > # owner: OPAM+DRA-Admin
> > # group: OPAM+None
> > user::rwx
> > user:OPAM+DRA:rwx
> > group::r-x
> > mask:rwx
> > other:r-x
> > default:user::rwx
> > default:user:OPAM+DRA:rwx
> > default:group::r-x
> > default:mask:rwx
> > default:other:r-x
> >
> > Fresh installation:
> >
> > # file: /tmp
> > # owner: OPAM+DRA-Admin
> > # group: OPAM+None
> > # flags: --t
> > user::rwx
> > group::rwx
> > other:rwx
> > default:user::rwx
> > default:group::r-x
> > default:other:r-x
> >
> > I expect that the extra OPAM+DRA:rwx on the old installation was
> manually added by me, years ago. What are the "mask" entries all about?
> >
> > The default:mask entry seems to be the crucial one, as if I do setfacl
> default:mask:rwx /tmp on the fresh installation, then I get the same
> behaviour as on the old installation.
> >
> > However, I'm struggling to find references for either what these mask
> entries are, or how they ever appeared?
> 
> If you search the web for "Posix acl mask" you'll find lots of
> information.  Here's one that seems pretty good:
> 
>    https://cs.unc.edu/help-article/posix-acls-in-linux/

Indeed, I got a lot further once I stopped looking for Cygwin-specific info. The most useful part was eventually finding this in the umask(2) man page (http://man7.org/linux/man-pages/man2/umask.2.html): "Alternatively, if the parent directory has a default ACL (see acl(5)), the umask is ignored". Which explains why I was seeing that behaviour, and it was owing to having added my user account (the OPAM+DRA) to the ACL as that of course added w to the mask.

Thanks for the help!


David


--
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: umask not working?

[Achim Gratz]

David Allsopp writes:
>> You have extended ACL on the object. And overall, umask is not a good
>> idea in Windows.
>
> "umask is not a good idea in Windows" - where's that come from?

Ask three people and get at least seven answers.

Actually Windows is a red herring IMHO, it's the combination of umask
with DACL is the thing that doesn't mix well unless you keep it in a
very tight box.  In your case, if you'd just remove the DACL from the
directories your repo is in (and any files and directories below
assuming that the ownership is the same for all of them) it'll probably
immediately start working as you expect it to.  Depending on which
volume the directory is actually on and what WIndows software tries to
touch it you might find that some of these come back after a while, I
generally avoid any system volume for that reason.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

--
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: umask not working?

[Brian Inglis]

On 2018-03-21 12:47, Achim Gratz wrote:
> David Allsopp writes:
>>> You have extended ACL on the object. And overall, umask is not a good
>>> idea in Windows.
>>
>> "umask is not a good idea in Windows" - where's that come from?
> 
> Ask three people and get at least seven answers.
> 
> Actually Windows is a red herring IMHO, it's the combination of umask
> with DACL is the thing that doesn't mix well unless you keep it in a
> very tight box.  In your case, if you'd just remove the DACL from the
> directories your repo is in (and any files and directories below
> assuming that the ownership is the same for all of them) it'll probably
> immediately start working as you expect it to.  Depending on which
> volume the directory is actually on and what WIndows software tries to
> touch it you might find that some of these come back after a while, I
> generally avoid any system volume for that reason.

If users remove directory DACLs, they should never try to use any non-Cygwin
programs to create or use files in those directories: without DACLs, files
created by non-Cygwin programs will have no access permissions, and can not be
accessed by any programs without elevated admin rights.

To support the interoperability offered by Cygwin, most users should ensure that
Cygwin directory DACLs match the default umask, so that all programs can create,
use, and change files in those directories.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: umask not working?

[Andrey Repin]

Greetings, Achim Gratz!

> David Allsopp writes:
>>> You have extended ACL on the object. And overall, umask is not a good
>>> idea in Windows.
>>
>> "umask is not a good idea in Windows" - where's that come from?

> Ask three people and get at least seven answers.

> Actually Windows is a red herring IMHO,

Not so much a red herring, but it was mentioned in the reply to the specific
issue, also because of how Windows actually implemented access control, which
is much more sane than simple POSIX permissions.

> it's the combination of umask
> with DACL is the thing that doesn't mix well unless you keep it in a
> very tight box.  In your case, if you'd just remove the DACL from the
> directories your repo is in (and any files and directories below
> assuming that the ownership is the same for all of them) it'll probably
> immediately start working as you expect it to.  Depending on which
> volume the directory is actually on and what WIndows software tries to
> touch it you might find that some of these come back after a while, I
> generally avoid any system volume for that reason.


> Regards,
> Achim.


-- 
With best regards,
Andrey Repin
Thursday, March 22, 2018 01:09:01

Sorry for my terrible english...


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