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 16:11:36 +0100
On 13 Jul 2007, at 15:34, Thomas Engelmeier wrote:
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.
As I've said already, I was wrong about this. I must have been
looking at an FSSpec or something. That said, FSRef still has path
length problems on filesystems that don't support HFS+-style file IDs.
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.
Sure, /.vol is not a documented or supported way of accessing files.
I wasn't advocating people actually using it, and it doesn't work
anyway except on HFS (and maybe AFP?). My point was just that FSRef
isn't some sort of magic thing that can't be done from BSD; it's
implemented on top of BSD, not alongside it.
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).
Indeed, the current limit is stupidly short. As I believe I said.
Actually it's worse than you state, because UTF-8 can take up more
than two bytes per code point. I think the worst case is four bytes
per code point (assuming well-formed UTF-8), so you can actually run
out of space with only half the number of code points you suggest.
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
The fact is that Cocoa and BSD contain a lot of legacy APIs dating
right back to the 1970s, so you can hardly claim that "some Cocoa
architect still drops the ball", given that much of the code in
question pre-dates the Mac.
there should be a severe usuabilty regression for the first time
since System 1 and the FAT-derived MFS?
The root problem is at the BSD layer, not at the Cocoa layer. Cocoa
is simply a victim of the fact that the kernel (somewhat) enforces a
path length limit that is much too small. It may also have path
length limits hard coded into it in places, but that's a much less
serious problem.
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.
And sure, you can try to use chdir() to change directory to the right
place and then open() it using a relative path, but because the
current directory is per-process, not per-thread, this approach is
not safe. I'm not even sure it will always work, and it only really
addresses one or two parts of the problem (since you can't e.g. mount
a filesystem on a mount point over the path length limit).
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.
If you had bothered to read my post properly, you would have noticed
that I was advocating *increasing* the path length limit in the
kernel. So yes, you could create subfolders in /Users. And probably
subfolders in subfolders in subfolders in Users, for that matter.
Another option would be to move the path-based BSD APIs into userland
and back them with a file-ID based approach inside the kernel, maybe
coupled with some new APIs at the BSD layer. But that's a *really*
big change as opposed to just a big change, and it's hard to support
on filesystems like FAT which don't have any concept of a file ID.
It is also non-portable, unlike the path-based APIs, which is a
concern for some people.
Anyway, we're heading way off topic now.
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