Re: FSGetCatalogInfo returns zero permissions for /Volumes/VolumeName directory
Re: FSGetCatalogInfo returns zero permissions for /Volumes/VolumeName directory
- Subject: Re: FSGetCatalogInfo returns zero permissions for /Volumes/VolumeName directory
- From: Jim Luther <email@hidden>
- Date: Tue, 28 Sep 2010 10:18:36 -0700
Hi,
The File Manager FSGetCatalogInfo and FSGetVolumeInfo APIs are built upon the system call getattrlist(2).
You download the FSMegaInfo sample from <http://developer.apple.com/library/mac/#samplecode/FSMegaInfo/Introduction/Intro.html> and then use it to see what various APIs layers are returning.
So, when you ask FSGetCatalogInfo() for kFSCatInfoPermissions, the File Manager asks getattrlist() for the ATTR_CMN_OWNERID, ATTR_CMN_GRPID, and ATTR_CMN_ACCESSMASK attributes. You can see what getattrlist() returns for those attributes using this FSMegaInfo command:
$ ./FSMegaInfo getattrlist -ATTR_CMN_OWNERID,ATTR_CMN_GRPID,ATTR_CMN_ACCESSMASK <path>
Likewise, asking for kFSCatInfoUserAccess ends up asking for the ATTR_CMN_USERACCESS attribute. This command show what getattrlist() returns for that attribute:
$ ./FSMegaInfo getattrlist -ATTR_CMN_USERACCESS <path>
FSMegaInfo also lets you see the results from stat(2) or lstat(2):
$ ./FSMegaInfo stat <path>
$ ./FSMegaInfo lstat <path>
I looked and the File Manager on Mac OS X never sets the kFSVolFlagHardwareLockedBit in FSVolumeInfo.flags -- so yes, it's weird that you see it set. The kFSVolFlagSoftwareLockedBit is set if the volume is mounted read-only (the MNT_RDONLY mount flag is set). Either of these FSMegaInfo command lines will show you the mount flags (MNT_RDONLY is 0x00000001 -- you'll need to look in <sys/mount.h> to find the definitions of the rest the flags):
$ ./FSMegaInfo getattrlist -ATTR_VOL_MOUNTFLAGS <path-to-mountpoint>
$ ./FSMegaInfo statfs / <path-to-mountpoint>
- Jim
On Sep 28, 2010, at 5:25 AM, el tasiziso wrote:
> Hi Everyone!
>
> I use 10.6.4 on Mac Pro.
>
> For some reason on limited number of machines we have the following behavior:
>
> The code
>
> FSCatalogInfo catalogInfo={0};
> err = FSGetCatalogInfo( &ref, kFSCatInfoNodeFlags | kFSCatInfoVolume |
> kFSCatInfoPermissions, &catalogInfo, NULL, NULL, NULL );
> if ( err == noErr )
> {
> UInt16 mode((reinterpret_cast<FSPermissionInfo*>(catalogInfo.permissions))->mode);
> }
>
> have mode containing zero. The ref is valid and pointing to HFS+
> Journaled local volume. How can mode == 0?
>
> The more interesting we have when we try
>
> FSVolumeInfo volumeInfo={0};
> // get volume flags
> if (noErr == (err = FSGetVolumeInfo(catalogInfo.volume, 0, NULL,
> kFSVolInfoFlags, &volumeInfo, NULL, NULL)))
> {
> // no error
> if ( 0 != (volumeInfo.flags & kFSVolFlagHardwareLockedMask))
> {
> // volume is locked by hardware
> ret = true;
> }
> }
> for the catalogInfo returned at the top - we have the hardware lock
> enabled return. Weird.
> When we try stat function from sys/stat.h
>
> if ( err == noErr )
> {
> UInt16 mode((reinterpret_cast<FSPermissionInfo*>(catalogInfo.permissions))->mode);
>
> if (0 == mode)
> {
> struct stat s = {0};
> stat(sFullPath.c_str(), &s);
> if (!(s.st_mode & S_IWUSR))
> {
> // user does not have access to write
> ret = TRUE; //<<<<<<< we do not get here, when more == 0
> }
> }
>
>
> Can anyone explain this?
> _______________________________________________
> 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