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 <vivek_ve...@apple.com> wrote: > > >> On Feb 23, 2018, at 3:56 PM, James Bucanek <subscri...@gloaming.com> 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 (Filesystem-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/filesystem-dev/vivek_verma%40apple.com >> >> This email sent to vivek_ve...@apple.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/filesystem-dev/luther.j%40apple.com > > This email sent to luthe...@apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Filesystem-dev mailing list (Filesystem-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/filesystem-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
