Re: Philosophy of FSRef - way
Re: Philosophy of FSRef - way
- Subject: Re: Philosophy of FSRef - way
- From: Eric Schlegel <email@hidden>
- Date: Fri, 11 Feb 2005 10:09:43 -0800
On Feb 11, 2005, at 9:55 AM, Ed Baskerville wrote:
Say you're using an app that has the notion of a "project" that
contains references to other files. It stores both pathnames and
FSRefs to these files. The user has previously made a backup of one
of these files in a different location, and, after making some
changes to the file, decides to revert to the backup. They* move the
file out of its current location, and move the backup to where it
just was, so that the project begins using the backup rather than the
file with the unwanted modifications.
You can't store FSRefs on-disk, because they contain data that can be
invalidated when the machine reboots (synthetic directory IDs for
directories on non-HFS volumes, for example). If you're storing data
about files in your project to disk, then you must use an alias; but
aliases store both the path and file ID/volume info, and in Mac OS X
10.2 and later, aliases will attempt to use the path first, so the case
you're describing will actually work exactly as the ordinary user would
expect: the backup file that was moved back into its original location
and name will be the file that is used by the project.
-eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden