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: Thomas Engelmeier <email@hidden>
- Date: Fri, 13 Jul 2007 16:34:07 +0200
Am 13.07.2007 um 14:06 schrieb Alastair Houghton:
This isn't especially surprising, because (if I remember rightly)
FSRefs internally store a path (on Mac OS X, anyway; earlier
versions presumably hold a CNID instead).
That is at best an implemenation detail, as a FSRef is not a
recounted CFTypeRef, and there is no way to store a 1024 byte path
(or even a 512 byte name + 8 byte dirID) in a 80 byte entity. Use the
list archives of Carbon dev. I'd consider .volfs is an abstraction to
expose unique HFS+ directory-IDs in a uniform way without introducing
new BSD SPIs.
It's easy to get the impression that FSRef is a workaround for this
problem, particularly because FSRefs constructed using legacy
Carbon APIs may point to something in the fake /.vol folder (on HFS
+ anyway), which I believe is used to provide direct access to
files by CNID (and which can, on HFS+, be used to access files
whose pathnames are too long). This trick won't work at all on
other filesystems, I shouldn't think.
And there were public mails on Carbon-dev stating the way that works
is going to vanish in upcoming OS releases. In contrary to FSRefs.
but that limit should be larger IMO and configurable via sysctl().
Guaranteed one folder deep hierarchies should be enough for
everyone ;-) (512 bytes for 256 Asian glyphs. Once for folder-, once
for filename and there is no more room for the '/' in 1024 bytes).
It'd also be better if the filesystem enforced the limit (e.g. by
preventing renames of folders higher up the hierarchy that result
in some file lower down having a path that is too long).
Because some Cocoa architect still drops the ball and considers
absolute paths + NSStrings as the best design choice there should be
a severe usuabilty regression for the first time since System 1 and
the FAT-derived MFS?
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.
That either means restricting the nesting depth of folders such
that the maximum length filename (plus one for the separator)
multiplied by the depth can't exceed the maximum path length,
Currently that means: No subfolders in /Users. I'd recommend you to
reconsider the implications.
Regards,
Tom_E
_______________________________________________
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