On Sep 24, 2013, at 3:54 AM, Ken Thomases <k...@codeweavers.com> 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.
Charles
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
