Re: Finder caching mount volume space information
Re: Finder caching mount volume space information
- Subject: Re: Finder caching mount volume space information
- From: Steve Goddard <email@hidden>
- Date: Wed, 20 Jul 2011 15:01:19 -0700 (PDT)
Hi Jim,
I built and ran your test application, and it indeed displays stale data. I did a dtruss on it, including verifying the debug log on my own file system. I don't see any requests going to my file system. I also ran it against a SMB share mount under dtruss too and didn't see any notable file IO for the mount path.
Both CFURL and File Manager paths were identical.
I also download and have run the FSMegaInfo test tool, and that appears to do do a getattrlist on the path so gets the updated information.
I will try and see why this difference occurs.
Thanks.
Steve
----- Original Message -----
> From: "Jim Luther" <email@hidden>
> To: "Steve Goddard" <email@hidden>
> Cc: email@hidden
> Sent: Tuesday, July 19, 2011 8:49:53 PM
> Subject: Re: Finder caching mount volume space information
>
> Steve,
>
> Do you set the VOL_CAP_FMT_FAST_STATFS volume capability bit? If you
> don't, that could be the problem. If you don't set the
> VOL_CAP_FMT_FAST_STATFS volume capability bit, the Carbon File
> Manager and CFURL property APIs cache the mutable volume size
> information for around 100 seconds.
>
> However, if you set the VOL_CAP_FMT_FAST_STATFS volume capability
> bit, be aware that your file system will see a lot more statfs or
> getattrlist requests for volume information. Here's the
> documentation for that bit:
>
> * VOL_CAP_FMT_FAST_STATFS: This bit is used as a hint to upper
> layers
> * (especially Carbon) that statfs() is fast enough that its results
> * need not be cached by those upper layers. A volume that caches
> * the statfs information in its in-memory structures should set this
> bit.
> * A volume that must always read from disk or always perform a
> network
> * transaction should not set this bit.
>
> So, before you set VOL_CAP_FMT_FAST_STATFS, make sure your file
> system doesn't fall into the category that last sentence refers to.
>
> If you're already setting VOL_CAP_FMT_FAST_STATFS, then maybe there's
> a bug. To get the volume size information, the Finder either uses
> FSGetVolumeInfo and asks for the kFSVolInfoSizes info, or it uses
> the CFURL file property APIs (CFURLCopyResourcePropertyForKey or
> CFURLCopyResourcePropertiesForKeys) and asks for the
> kCFURLVolumeTotalCapacityKey and kCFURLVolumeAvailableCapacityKey
> property values. Here's source for a little command line tool that
> displays values from both API sets:
>
> #include <CoreServices/CoreServices.h>
> #include <CoreFoundation/CoreFoundation.h>
> int main (int argc, const char * argv[]) {
> if ( argc == 2 ) {
> const char * path = argv[0];
> FSRef ref;
> if ( FSPathMakeRef((UInt8 *)path, &ref, NULL) == noErr ) {
> FSCatalogInfo catalogInfo;
> if ( FSGetCatalogInfo(&ref, kFSCatInfoVolume,
> &catalogInfo, NULL, NULL, NULL) == noErr ) {
> FSVolumeInfo info;
> if ( FSGetVolumeInfo(catalogInfo.volume, 0, NULL,
> kFSVolInfoSizes, &info, NULL, NULL) == noErr ) {
> printf("File Manager: path = %s, totalBytes =
> %lld, freeBytes = %lld\n", path,
> info.totalBytes, info.freeBytes);
> }
> }
> }
>
> CFURLRef url =
> CFURLCreateFromFileSystemRepresentation(kCFAllocatorDefault,
> (UInt8 *)path, strlen(path), TRUE);
> if ( url != NULL ) {
> CFNumberRef volumeTotalCapacity;
> CFNumberRef volumeAvailableCapacity;
> UInt64 totalCapacity;
> UInt64 availableCapacity;
> if ( CFURLCopyResourcePropertyForKey(url,
> kCFURLVolumeTotalCapacityKey, &volumeTotalCapacity,
> NULL) ) {
> if ( CFNumberGetValue(volumeTotalCapacity,
> kCFNumberSInt64Type, &totalCapacity) ) {
> if ( CFURLCopyResourcePropertyForKey(url,
> kCFURLVolumeAvailableCapacityKey,
> &volumeAvailableCapacity, NULL) ) {
> if (
> CFNumberGetValue(volumeAvailableCapacity,
> kCFNumberSInt64Type, &availableCapacity) ) {
> printf("CFURL: path = %s, totalCapacity =
> %lld, availableCapacity = %lld\n", path,
> totalCapacity, availableCapacity);
> }
> }
> }
> }
> }
> }
> return 0;
> }
>
> (Note: the freeBytes and availableCapacity might not be exactly the
> same -- different code paths in the system)
>
> If this tool is displaying the correct values, then the code the
> Finder calls isn't caching. The Finder's GetInfo window might be
> caching -- try closing that window and reopening it to see if the
> values update.
>
> If after this, you think there's a bug in Apples code, write a Radar
> and include screen shots from the Finder, the output of df, and the
> output of that tool above.
>
> - Jim
>
> On Jul 19, 2011, at 6:36 PM, Steve Goddard wrote:
>
> > Hello,
> >
> > I am debugging an issue with our file system which on OS X 10.7
> > where Finder caches the volume mount information for the size
> > capacity and available bytes of our volume. We are a specialized
> > network mount where "new" mounts can come and go underneath this
> > overall mount. This has the effect of dynamically changing the
> > mount volumes capacity and available space under that "super"
> > mount.
> > How can I get Finder to purge its information?
> >
> > When I perform a GetInfo on the mount in the Finder window, I see
> > lots of statfs calls which in turn result in VfsGetattr calls into
> > our driver which return the correct f_bavail and f_bfree fields,
> > and return the updated information from dtruss or fs_usage but
> > still Finder shows the initial quantities. df works correctly and
> > shows the updated information.
> >
> > How do I cause Finder to update?
> >
> > Thanks.
> > Steve
> > _______________________________________________
> > 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