Re: How to discover the volume id to use in a File Reference URL
Re: How to discover the volume id to use in a File Reference URL
- Subject: Re: How to discover the volume id to use in a File Reference URL
- From: Ken Thomases <email@hidden>
- Date: Tue, 24 Sep 2013 16:47:23 -0500
On Sep 24, 2013, at 11:41 AM, Charles Srstka wrote:
> On Sep 24, 2013, at 3:54 AM, Ken Thomases <email@hidden> wrote:
>
>> I believe one solution is the searchfs() routine. Of course, that's a potentially slow or expensive operation. In theory, I suppose, searching for a file by its ID should be no slower than converting a file reference URL to a file path URL.
>
> Ironically, searchfs() was the example I was going to pipe in and suggest he might have been using, as an example of how he might be stuck with a file ID that he's trying to convert to a URL. The trouble with searchfs() is that if you try to ask it to return ATTR_CMN_FULLPATH, it immediately bails out with EINVAL. The source code for XNU reveals what attributes it will let you request:
>
> /*
> * Fail requests for attributes that HFS does not support for the
> * items that match the search criteria. Note that these checks
> * are for the OUTBOUND attributes to be returned (not search criteria).
> */
> if ((ap->a_returnattrs->commonattr & ~HFS_ATTR_CMN_VALID) ||
> (ap->a_returnattrs->volattr != 0) ||
> (ap->a_returnattrs->dirattr & ~HFS_ATTR_DIR_VALID) ||
> (ap->a_returnattrs->fileattr & ~HFS_ATTR_FILE_VALID) ||
> (ap->a_returnattrs->forkattr != 0)) {
> return (EINVAL);
> }
> And in the header:
>
> #define HFS_ATTR_CMN_VALID \
> (ATTR_CMN_NAME | ATTR_CMN_DEVID | \
> ATTR_CMN_FSID | ATTR_CMN_OBJTYPE | \
> ATTR_CMN_OBJTAG | ATTR_CMN_OBJID | \
> ATTR_CMN_OBJPERMANENTID | ATTR_CMN_PAROBJID | \
> ATTR_CMN_SCRIPT | ATTR_CMN_CRTIME | \
> ATTR_CMN_MODTIME | ATTR_CMN_CHGTIME | \
> ATTR_CMN_ACCTIME | ATTR_CMN_BKUPTIME | \
> ATTR_CMN_FNDRINFO |ATTR_CMN_OWNERID | \
> ATTR_CMN_GRPID | ATTR_CMN_ACCESSMASK | \
> ATTR_CMN_FLAGS | ATTR_CMN_USERACCESS | \
> ATTR_CMN_FILEID | ATTR_CMN_PARENTID )
> #define HFS_ATTR_DIR_VALID \
> (ATTR_DIR_LINKCOUNT | ATTR_DIR_ENTRYCOUNT | ATTR_DIR_MOUNTSTATUS)
> #define HFS_ATTR_FILE_VALID \
> (ATTR_FILE_LINKCOUNT |ATTR_FILE_TOTALSIZE | \
> ATTR_FILE_ALLOCSIZE | ATTR_FILE_IOBLOCKSIZE | \
> ATTR_FILE_CLUMPSIZE | ATTR_FILE_DEVTYPE | \
> ATTR_FILE_DATALENGTH | ATTR_FILE_DATAALLOCSIZE | \
> ATTR_FILE_RSRCLENGTH | ATTR_FILE_RSRCALLOCSIZE)
>
> Indeed, the only allowed attribute that uniquely identifies the file, so far as I can tell, is the file ID, leaving you with exactly the conundrum that Ben is in now. The only way that I've found to get from the results of searchfs() to a decent path or URL usable by any other API on the system is to either:
>
> 1. Use the private fsgetpath SPI, which is what FSCatalogSearch seems to do, or:
>
> 2. Build a reference NSURL from scratch.
>
> Both of these are pretty bad, but of the two, building the NSURL seems the less evil. If there's an actually good way to get from the results of searchfs() to something actually usable, I'd be very interested to hear what it is myself. It's pretty clear, however, that searchfs() is *not* going to be the answer to Ben's question. It's also pretty clear that searchfs() is a near-useless API since the only way to get usable results from it is essentially to hack something, but that's a problem for another thread.
I was not aware of those limitations. Thanks for enlightening me. It looks, though, like you could reconstruct a path by working your way back from the item through its ancestors, getting each name along the way, using ATTR_CMN_NAME and ATTR_CMN_PARENTID. Not graceful, but should work.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden