Re: What are the official limits of Cocoa when it comes to the length of path names?
Re: What are the official limits of Cocoa when it comes to the length of path names?
- Subject: Re: What are the official limits of Cocoa when it comes to the length of path names?
- From: Gregory Weston <email@hidden>
- Date: Fri, 13 Jul 2007 13:16:35 -0400
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:
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.
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.
_______________________________________________
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