On Sep 24, 2013, at 11:41 AM, Charles Srstka wrote: > On Sep 24, 2013, at 3:54 AM, Ken Thomases <[email protected]> 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 protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
