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: Alastair Houghton <email@hidden>
- Date: Fri, 13 Jul 2007 13:06:45 +0100
On 13 Jul 2007, at 11:36, Stéphane Sudre wrote:
Plain path names are always problematic. You should try and use
higher level abstractions like NSURL/CFURL or FSRef where
possible. For drag and dropping of files, a Text Field is not the
best choice, and if only for the reason that the HIG recommends to
avoid showing file paths to the user.
I agree with you. The problem here is that I didn't write any line
of code (this project is code free) to make this happen. The
limitation is in the Cocoa framework.
Well it may actually be in the kernel. If it's in the framework then
it should be fixed, since there's no reason for the framework to
limit the length of a path.
Of course, that all depends on your individual case.
Actually, I'm tracking an issue with Alias resolution and I'm
testing different cases to see where the problem might come from.
My biggest surprise so far is that the same limit affects
CFURLGetFSRef.
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). Carbon is implemented *on top* of
the BSD layers, not as a separate subsystem as some people seem to
suppose. It does have one or two private hooks into the kernel, but
those are mostly there for compatibility purposes, not to implement
additional functionality that you can't get anyway with published APIs.
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.
I certainly consider all of this to be a bug in the system, even more
so because application behaviour is inconsistent as a result (and not
in a way that an ordinary end user would understand). The root of
the problem, unfortunately, lies in the kernel, which makes use of
PATH_MAX (aka MAXPATHLEN) in many different places. It clearly has
to have an overall limit for security reasons (in case it copies a
path into kernel memory), but that limit should be larger IMO and
configurable via sysctl().
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). 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, or it means tracking the
maximum path length for each object subordinate to each folder on the
disk (which sounds expensive).
(I'll also add, before someone whines that they need PATH_MAX for
some reason, that there's a perfectly good system call, pathconf(),
that can return filesystem-specific information. And anyway, in
userland programs, there's normally little to be gained from limiting
the path length; some server processes might do so for security
purposes, but otherwise I don't see a benefit.)
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