Re: Tracking files the right way
Re: Tracking files the right way
- Subject: Re: Tracking files the right way
- From: Bill Bumgarner <email@hidden>
- Date: Thu, 29 Aug 2002 17:47:06 -0400
Yes -- you are absolutely correct, I screwed up my vocabulary and was,
in this context, using Alias and FSRef to mean Alias. Sorry about that.
It doesn't change the original point: That using Aliases does not
necessarily yield an intuitive user experience without a bunch of
additional effort on the part of the developer. I have wasted many
hours talking my mom or sister through a problem related to an Alias
pointing to the wrong thing because it "behaved correctly".
Some examples (maybe these aren't directly Alias related, but these all
have to do correctly tracking file locations):
- iTunes effectively expands all paths contained in the music database
such that the stored path (alias? doesn't matter) does not contain any
symlinks or other abbreviated forms of paths (like, say, ~bbum/ instead
of /private/automount/foo/dog/Users/bbum). As a result, iTunes breaks
horribly if the path to your home account changes. In particular, it
doesn't work when using the same account from an OS X Server vs. OS X
client box on a single network.
- (maybe fixed in 10.2) If I set OmniWeb as my default browser and
upgraded OmniWeb in the typical 'mount the disk image, drag and drop
the app into my Applications directory, click "replace" when the finder
asks', the system preferences happily maintains a reference to the
ORIGINAL version of OmniWeb -- the version that is now in the trash!
As soon as I empty the trash, SP reverts to IE. Not at all a good
user experience.
- If I edit an ASCII template file for Radio UserLand (a fairly
typical old school Mac classic App) with TextEdit, emacs, or any other
editor that saves a backup file and does so atomically (as a good
program should), Radio Userland will continue to use the last revision
of the file and won't reference the new file until I save the file
*again* and thereby delete the backup file to which the reference was
still pointing. Office used to do something similar and I frequently
found myself editing the OLD version of some random document where I
had been sent a newer version via email and had tried to copy it over
the old version.
Now, certainly, most of these issues could be considered actual bugs in
the applications and not necessarily bugs inherent to the design of
aliases (or file system references). But that is part of the point --
this is something that the developer needs to think through carefully.
The default behavior of either Aliases or Just Plain Paths is far from
ideal.
The one default behavior of Aliases that I find particularly annoying
is epitomized by the third example. It is occasionally very handy
that an app like IB, TextEdit, emacs, etc... saves the last version as
a backup version (i.e. edit 'foo.txt', click 'save', TE moves the
current file to foo~.txt and saves the new content to foo.txt).
However, Aliases interaction with this situation is really damned
annoying -- an Alias will follow foo.txt to foo~.txt. It should note
that 'foo.txt' is there, of the same type, and has a later modification
date and optionally ask the user if the alias should be fixed to point
to the new version (or, optionally, just fixed the alias).
b.bum
On Thursday, Aug 29, 2002, at 16:50 US/Eastern, Nicholas Riley wrote:
A FSRef is not an alias; a FSRef is only valid for the lifetime of the
app. Aliases include path information. If you use aliases sensibly
in your code (and their behavior is free of bugs), everything should
work.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.