[OT] Re: What are the official limits of Cocoa when it comes to the length of path names?
[OT] Re: What are the official limits of Cocoa when it comes to the length of path names?
- Subject: [OT] Re: What are the official limits of Cocoa when it comes to the length of path names?
- From: Alastair Houghton <email@hidden>
- Date: Fri, 13 Jul 2007 18:47:30 +0100
On 13 Jul 2007, at 18:16, Gregory Weston wrote:
Alastair Houghton wrote:
Cocoa is the only framework that still enforces path usage (by
using them all over instead of an NSFileObject or so, and many path
only APIs). In contrast to the rest of the OX X API set. The BSD
layer has relative paths + inodes, Carbon FSRefs.
You can't open a file using its inode number alone. At least, I
don't think you can. And if you're going to store the location of a
file, you need an absolute path.
That last sentence is wrong in two different directions at once:
Not necessarily, no. It depends on what location you're storing and
why. I was also talking (in that sentence anyway) about the BSD
layer, not about things in the Carbon framework.
1. There are certainly alternatives to absolute paths as persistent/
transferable file locations. In particular, Mac OS aliases do
admirably as long as you're actually staying within the platform.
Aliases are indeed a good idea, though even they can be broken under
some circumstances. Also, Mac OS aliases (as opposed to BSD
symlinks) are not a filesystem feature, so they only work for
programs that explicitly support them. This is a bit of a shame,
because they have definite advantages over symlinks for the end user.
2. Paths aren't reliable as long-term file references on Mac OS X.
In particular, they don't track an object in the file system; they
track a location which may not exist (because volumes may be
unmounted, or mounted at a different mount point) and may not point
to what the user wants/expects even if it does.
That's certainly true for references on non-root filesystems, though
you can keep the path relative to the mount point (which is absolute
from the perspective of the individual filesystem, just not the root
filesystem), plus something to identify the filesystem. Or, again,
you could use an alias... I seem to recall that aliases are even
better for network filesystems because they automount the networked
filesystem if it isn't already mounted. This problem isn't specific
to Mac OS X; it happens for *any* system with removable filesystems
of any kind.
One serious disadvantage of aliases is that they aren't easily
editable in a text editor, unlike pathnames. You might be able to
store an encoded alias in a text file, but it'd be a nuisance to edit.
All of this is, of course, off topic.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden