Re: Globally, persistently identifying a file
Re: Globally, persistently identifying a file
- Subject: Re: Globally, persistently identifying a file
- From: Tilghman Lesher <email@hidden>
- Date: Fri, 27 Apr 2012 13:06:50 -0500
On Fri, Apr 27, 2012 at 12:51 PM, Nick Zitzmann <email@hidden> wrote:
>
> On Apr 27, 2012, at 11:29 AM, Jens Alfke wrote:
>
>>
>> On Apr 26, 2012, at 1:36 PM, Nick Zitzmann wrote:
>>
>>> I know about bookmarks, but the bookmark data is not persistent between reboots despite still being resolvable between reboots.
>>
>> What does that mean? I haven’t used bookmarks myself, but if they’re based on aliases they’re persistent. After all, an alias file contains alias/bookmark data, and those work across reboots.
>>
>>> I need something that will not change under any circumstances other than deleting and re-creating the file/folder. This is so I can search for a value in a database corresponding to a file/folder.
>>
>> You probably don’t actually want that. Consider that most mechanisms for safely updating a file (including the ‘atomic’ modes of the Cocoa writeToFile: methods) end up deleting it and replacing it with a new file.
>>
>> It really sounds to me like an alias/bookmark is exactly what you’re looking for.
>
> It is what I'm looking for, but the problem is, bookmark data changes between reboots, which means I can't use the data for searching.
>
> I'm storing references to files in a database, and need to search the database to see if the database is aware of the existence of the file. Doing an in-memory search by resolving the bookmark data for each item in the database scales very poorly. Which means that the reference must not change if the file is renamed or moved, the underlying folder structure changes (other than the volume), the file is modified, the OS is rebooted, or the OS is updated. If the file is copied and the original is deleted, then that's okay. So far, the only things I've found that have stayed constant when everything else changes (even when the file is overwritten!), at least for HFS+ volumes, are the inode and volume numbers. And for remote volumes, I've found that the inode and file system creation date don't change. I just need to know whether I can rely on this or not for the purpose of searching.
Here's another idea: instead of relying upon the file's inode, use
the containing directory's inode number and a combination of the inode
number and the name of the file. It will work fine if the Cocoa API
deletes and recreates the file. It will also work fine if the
containing directory is moved to another part of the filesystem. If
either the filename or the inode don't match, you can use that
information to update your database on each run. This especially
works well with applications, since applications are themselves
directories.
-Tilghman
_______________________________________________
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