Re: So what does VOL_CAP_INT_USERACCESS actually mean?
Re: So what does VOL_CAP_INT_USERACCESS actually mean?
- Subject: Re: So what does VOL_CAP_INT_USERACCESS actually mean?
- From: Jim Luther <email@hidden>
- Date: Fri, 23 Feb 2018 18:58:00 -0800
Here's something that is kind of related that I ran into recently.
If you have code that is checking the ownership and permissions of a file
system object and attempting to correct the ownership and permissions if it is
wrong, don't bother if the MNT_IGNORE_OWNERSHIP mount flag is set -- nothing
will change 😀. In addition, that attempt to set the ownership and permissions
WILL cause an FSEvent which causes the Finder (and other things listening to
FSEvents) do wake up and do some work.
I had some code which was called quite often and was making that useless
attempt to set the ownership and permissions -- it kept the Finder very busy.
Oops.
- Jim
> On Feb 23, 2018, at 5:17 PM, Vivek Verma <email@hidden> wrote:
>
>
>> On Feb 23, 2018, at 3:56 PM, James Bucanek <email@hidden> wrote:
>>
>> Hello,
>>
>> I have a (low priority) question about the VOL_CAP_INT_USERACCESS volume
>> attribute.
>>
>> I often get the ATTR_CMN_USERACCESS value for files via getattrlist().
>
> Surely then you would want to question VOL_CAP_INT_ATTRLIST :-) ?
>
>> Today, while doing unrelated research, I stumbled across the description for
>> VOL_CAP_INT_USERACCESS which says "If this bit is set the volume format
>> implementation supports the ATTR_CMN_USERACCESS attribute."
>>
>> This took me quit by surprise, since ATTR_CMN_USERACCESS has never failed
>> me. In testing I've now identified volumes that report
>> VOL_CAP_INT_USERACCESS=0, but when I get the attributes for a file and
>> request ATTR_CMN_USERACCESS it reports completely reasonable values.
>>
>> So what does it mean, in terms of requesting the ATTR_CMN_USERACCESS
>> attribute, if a volume reports VOL_CAP_INT_USERACCESS=0.
>>
>
> getattrlist(2) used to be part of the Filesystem implementation and so it was
> possible for you to potentially not get ATTR_CMN_USERACCESS back from a
> particular implementation. getattrlist(2) today is implemented in VFS so this
> has become somewhat non useful for getattrlist(2) itself but can be useful
> for getdirentriesattr(2) (which is deprecated in favor of
> getattrlistbulk(2)).
>
> (As for VOL_CAP_INT_ATTRLIST, we OR it in always so you'll never see it as 0)
>
> This sounds like something we should fix in our documentation so please file
> a bug.
>
>
>> Thanks,
>>
>> James
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Filesystem-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Filesystem-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden