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: Fri, 30 Aug 2002 09:09:13 -0400
On Friday, Aug 30, 2002, at 01:20 US/Eastern, Rosyna wrote:
... description of not exposing symlinks, etc, deleted ...
Why do this at all? I strongly advocate people showing the HFS path,
as it's the one most recognizable to users from the desktop. Unless
they are using UFS, users don't see a / on their desktop, and even
then, they don't see the Volumes directory. However, if the path is
copied, it should copy the POSIX path. (heck, or just show both)
If you aren't careful, you'll end up exposing hunks of paths that
should never be exposed. Beyond that, if a path refers to a location
within the user's home directory, then that fact should be symbolically
reflected in the path -- i.e. if an app wants to keep around a
reference to /Volumes/Data/Users/bbum/Documents/Notes.html, it should
be stored as ~bbum/Documents/Notes.html (along with all of the
wonderful Alias functionality, if available).
Too many apps on OS X end up expanding symlinks, mount points, and the
path to the home directory in fashions that become really ugly to the
user and potentially break things significantly as the user moves from
one host to another and uses mounted filesystems to do so.
It is a case of the developer making sure that they don't convert from
a POSIX path to some kind of direct file references (FSRef or, I
believe, FSSPec) and back again in a fashion that loses the original
POSIX path.
Very likely, there are "opportunities for improvement" in the way the
system handles and presents paths in that the Finder and the Open/Save
Panels present a slightly different and more friendly view of the
filesystem than what is actually present on the system. In most
cases, the paths returned by the APIs remain relatively friendly but it
wouldn't surprise me if there are situations where the path returned is
suboptimal (i.e. contains /private/automounts instead of the symlink
found in /Network -- the former won't work on the server itself, the
latter will).
And although FSRefs use the same sorta "Technology" as aliases, they
are not the same. On UFS, FSRefs are not valid between processes
whereas aliases are. Even with HFS+, FSRefs might not be valid between
restarts.
(Yes -- I was using FSRefs and Aliases to mean "aliases" in the
previous discussion. Sorry about that.)
To assume everything is on HFS+ will lead to bugs for a growing
percentage of the user base. Between iDisk and the relatively
seamless ability to mount Windows fileshares, it is becoming more and
more common for an OS X consumer level user to actively use non-HFS
filesystems as a normal part of their computer usage.
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.