g layout would seem a long-term decision
regarding Cygwin <-> Linux interoperability. Please consider.
On 01/13/2016 07:12 AM, Corinna Vinschen wrote:
> On Jan 12 22:17, random user wrote:
>> Something I wasn't aware of at the time of our prior discussion is
>> that
Something I wasn't aware of at the time of our prior discussion is
that the Linux NTFS-3g driver already supports Linux extended ACLs
on NTFS. This is discussed at
http://www.tuxera.com/community/ntfs-3g-advanced/ownership-and-permissions/
I explored taking a flash card back and forth between C
Let me take a try on Achim's case with/refining the "alternative
idea"; this seems one of the kinds of cases that it is intended to
help.
(Corinna, I hope at least some of the ideas here prove helpful to you,
and my posting this isn't (too) annoying. Again, please
expect/forgive glitches as I'm n
>> On 4/22/2015 7:21 PM, John Orr wrote: ...
Would I be right in guessing that your samba server is doing
authentication using a /etc/samba/smbpasswd file?
If that is the case, the output you show matches my experience. Files
with owner matching the logged in user in such a case one end up with
Thanks for the explanation/correction about umask's non-impact if
there are default ACL entries. I'm not recalling exactly what I had
seen on Linux that made me think there was an impact.
>> If the incoming, inherited ACL contains the three entries for user,
group, and other, it's with very hi
Hmm... Seems my Item 1 and Item 2 are more related in your design
thinking than I had realized.
>>> "extended ACLs" (is that the proper phrasing?),
>> (default ACL entries in POSIX speak, inheritable ACEs in Windows)
I'm looking for the term that would distinguish whether on Linux ls
shows a '+'
Hi again, Corinna.
I appreciate these recent changes, the more complete Posix ACL support
looks beneficial for sharing/syncing files between Cygwin and Linux
machines, and for more compatible scripting.
But I've noticed a few possibly-concerning items:
Item 1:
>> - I introduced a change in chmo
>> Please try the latest developer snapshot from
https://cygwin.com/snapshots/
Best I can spot from some simple hand-test cases, does look
consistently '---' now for the group SID = user SID case.
Not so far seeing any surprise change to the != case.
Thanks.
--
Problem reports: http://
Thanks for the reply. Seems we've maybe miscommunicated a bit tho.
So not meaning to argue, just to try to clarify, let me try again:
None of my concern, none of my examples, were intended to involve any
ACLs other than those created by Cygwin touch, chgrp, chmod, and
setfacl. (setfacl only used
Re the user SID != group SID, chmod -x case: Thanks, sorry to have
wasted your time. It does seem the same on Linux, and chmod ug-x does
appear to work correctly. My bad.
Re the user SID = group SID case:
I'm not offhand spotting how to use chmod to create the ACL your "They
do:" example displays
The changes regarding the user SID = group SID case look generally good
to me.
Thanks for considering the idea.
I do wonder if it is best that the Everyone privileges would "leak" into the
group permission mode/mask tho, either at the Posix or ACL levels. They
don't
seem to for user SID != group
Umm... Sorry! I hope it's clear to all, I meant Corinna !
On 2/26/2015 9:27 PM, random user wrote:
>> Regarding Corrinne's proposal to treat SYSTEM's ACE distinct from others
>> in forming the apparent group permission "mask":
>>
>> Might it be sen
Regarding Corrinne's proposal to treat SYSTEM's ACE distinct from others
in forming the apparent group permission "mask":
Might it be sensible to do somewhat similar for the case where a file's
owner is the same as its primary group (i.e., same SID)? It has seemed
the chmod behavior for this case
13 matches
Mail list logo
