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 15:49:54 -0400
Thanks!
I haven't looked deeply at the APIs to see what can be done
automatically, but I have noticed a couple of critical mistakes in some
apps.
Namely, iTunes completely hoses the references to music stored on
mounted filesystems. It ends up with a path that refers to the music
through /private/automount -- a path that really should be hidden from
the user (use /Volumes/* instead -- in either case, you'll have to
watch out for changing volume names!)
Also -- make sure you don't expand symlinks and the like in the path
(which can happen "automatically" when a path is manipulate via certain
APIs). Example: an OpenPanel will return /some/path/to/a/file where
the 'to' element is actually a symlink off to
/some/nasty/path/the/user/should/never/see/that/leads/to/a/file. Some
apps have a habit of ending up with the second path, thus confusing the
user and often screwing up the reference in that symlinks are often
used to normalize the view of a filesystem between two machines
(typically, between a server and a client or between two clients who
have slightly different configurations -- OS X Server uses symlinks to
simulate a mount such that a user with an AFP mounted home directory
can still use the server without requiring a self referencing mount).
The key is to use the path as presented by the Finder or Open/Save
Panel's directly. If you are going to do tracking (i.e. use FSRefs to
point to the underlying file such that the reference follows the file
as the user moves it), then store the original path along with the
FSRef so you can detect situations where the user may have done
something that results in the need to use the path, not the ref.
Another normalization that can greatly simplify the user experience and
the development issues is to employ both the concept of base paths and
search paths.
For base paths, the idea is that you have a path (or FSRef) that points
to some location that provides the base for subsequent references.
References to files within that location are relative to the base path.
See File wrappers and the like for a more formal OO API for working
with a base path.
Search paths solve a slightly different problem in that they are mostly
used to allow an app to find plugins and resources that may be found in
one of several relatively standard locations throughout the filesystem.
However, it is worth studying the APIs and concept guides in that it
provides some good hints as to how to manage sets of paths on the fly.
There really isn't a 100% correct answer to this particular problem.
Going with a pure FSRef (alias) or pure Path based implementation will
both lead to problems -- different problems, but both potentially
severe. A combination of the two with some well considered user
interaction will be a bit more complex, but will likely/often yield a
solution that makes for a considerably more pleasant user experience.
On Thursday, Aug 29, 2002, at 15:36 US/Eastern, Paul Nelson wrote:
Hi!
I saw your rant (and read the full rant) on the cocoa-dev mail list,
and I
agree with you on all points.
You mentioned:
- If you do use paths to refer to a file -- either directly storing the
path or through one of the Core APIs-- NORMALIZE THE DAMNED PATH FIRST!
Other than replacing /users/xxx with tilde, are there other
normalizations
that you would recommend? (perhaps you could post the answer on
cocoa-dev)
I'm going to be working on a Music-Graphing program which will maintain
paths to MIDI files and this was an issue that I had been worrying
about.
Thanks!
Paul Nelson
_______________________________________________
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.