I did an informal time test on the path resolution using NSURL with a known ID,
like this:
NSURL *itemRefUrl = [NSURL
URLWithString:@"file:///.file/id=1234.5678/"];
NSString *itemPath = [[itemRefUrl filePathURL] path];
I realise now that creating a file reference URL from a literal string this way
is dodgy because the textual form of the reference URL is not guaranteed to be
stable, but having said that the conversion process on my 2009 MacBook with
decent sized disk was around 0.1 milliseconds, so certainly acceptably quick
for practical applications.
-- Ben.
On 24 Sep 2013, at 23:48, Charles Srstka <[email protected]> wrote:
> On Sep 24, 2013, at 5:05 PM, Ken Thomases <[email protected]> wrote:
>
>>> Because if you had to do an entire drive search for every ancestor, that
>>> would quite likely take a *long* time to complete.
>>
>> I don't think that searchfs() _necessarily_ does a true full-drive search.
>> Given a unique file ID (ATTR_CMN_FILEID) in the search criteria, the file
>> system implementation could very well return in constant time. As I said
>> earlier, logically it could be as fast as resolving a file reference URL to
>> a file path URL, since that's what that amounts to.
>>
>> That said, I haven't investigated either by reading the source or by running
>> tests.
>
> In the extremely informal, non-scientific test I just ran, searching by
> ATTR_CMN_OBJID took approximately 10 seconds, and searching by
> ATTR_CMN_FILEID took about 15.6 seconds. I think it goes without saying that
> spending 10-15 seconds per ancestor in the file system hierarchy, per search
> result, is not a viable solution.
>
> Charles
>
_______________________________________________
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]
