Re: Globally, persistently identifying a file
Re: Globally, persistently identifying a file
- Subject: Re: Globally, persistently identifying a file
- From: Brian Bergstrand <email@hidden>
- Date: Thu, 26 Apr 2012 15:24:48 -0500
Prior to 10.6 you would use Alias records, but in 10.6 Apple added URL-based bookmarks (which are pretty much alias records with some new features).
Cocoa: NSURL bookmarks
C/C++: CFURL bookmarks
On Apr 26, 2012, at 2:09 PM, Nick Zitzmann wrote:
> I've searched around for solutions with no luck.
>
> I need to be able to identify a file globally and persistently (such that it still works after moving or overwriting a file, or re-mounting a volume, or after rebooting). File paths don't work, because even though they're technically unique, they break if the file or its underlying path components are renamed or moved. Carbon FSSpec data structures don't work, because they're not available to 64-bit apps. Cocoa NSURLFileResourceIdentifier objects don't work, because they aren't persistent across reboots.
>
> After a lot of searching and experimenting, I found that any given file has a constant number in a struct stat st_ino returned by stat() even if the file is moved or overwritten or the system is rebooted, and struct stat st_dev almost never changes as well even if the volume is unmounted and then remounted, with the only exception I've found being if the volume is a network volume (AFP, etc). I did a little reading, and found that network volumes can almost always be uniquely identified by their creation date, and that's the best UUID I can get for a network volume.
>
> So my question is: Am I on the right track here? Can I depend on these three things (struct stat st_ino, struct stat st_dev, and usually volume creation dates) never changing for a file/volume? Can I depend on the OS not using the same numbers twice? If not, then how can I best solve this problem? I'm targeting Lion.
>
> Nick Zitzmann
> <http://www.chronosnet.com/>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden