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 13:43:53 -0400
Seems the age old argument of aliases vs. hard paths, tracking files
vs. warning user has come up again. Some general rules of thumb that I
have found to render a relatively consistent environment.
The bottom line is that tracking a file automatically has some serious
disadvantages of an equal magnitude as keeping full path references.
- If you are going to track the file, *do not* track it to the trash!!!
I can't tell you the number of times I have run across apps that
happily maintain an FSRef straight into the trash can. Nice surprise
for the user when the trash is emptied
- If you are going to track a file, also store the path that the FSRef
was last on. If you find the file via the FSRef (i.e. in the
potentially moved place) AND the file still exists in the original
location, ask the user to resolve the duplication. I have been burned
several times when I use something that first makes a copy of the file
to be edited/manipulated, moves the original, and puts the new copy in
the original's location (which, btw, is the right thing to do -- the
ORIGINAL should remain as ORIGINAL as possible, save for a possible
location change).
- 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!
I.e. If the user stores something in the Documents/ directory of
their home account, store the path as '~/Documents' or
'~user/Documents'. This can greatly easy the pain of working with
certain applications in an account that can be accessed from multiple
machines on a network where the path to ~/ can change depending on
machine.
- If you store a thousand file references into some random area of a
Volume and the Volume name changes, you should only have to ask the
user ONCE where the files have been move to -- your app should be
bright enough to figure it out from that information! This is not
hard to do and affects both aliased and non-aliased storage paradigms
(i.e. if the user has copied the files and deleted the originals, for
example).
If you want the full rant, read this:
http://radio.weblogs.com/0100490/2002/03/26.html#a152
b.bum
_______________________________________________
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.