Home » Learning Curve » Developers Workshop
Yo Yer Paths IIThe promised followup to the original article.
On Bastille Day 2007 an interesting question was posed. Read about it here.
Funny things can namely happen when a file is sent down too deep into the file system hierarchy.
 
This isn't a new issue. There have always been system constraints when building a kernel. It's the name of the game. Static allocations are needed to hold system resources. Programmers have to know how big those allocations need be.
Microsoft have them in Windows and Unix has them as well. They're defined by the two macros PATH_MAX and NAME_MAX. Copy out and build the following code if you want to see how your system performs.
#include <limits.h>
#include <stdio.h>
int main (int argc, char *argv[]) {
printf("PATH_MAX: %d; NAME_MAX: %d.\n", PATH_MAX, NAME_MAX); return 0;
} |
You should get the following on Tiger or earlier.
| PATH_MAX: 1024; NAME_MAX: 255. |
The following comes from Free Shell.
./path-name_max
Max path is 4095
File max is 255 |
The Mail Archive reminds us of this tidbit.
| On NT systems and using the Unicode versions of Windows syscalls Windows supports up to 32 KB for pathnames with component names up to 255 bytes by using the \\?\ prefix. |
Otherwise Windows sets the limit to 260 bytes. Whereas several flavours of Unix now define PATH_MAX as 8192 bytes.
Clearly this isn't good enough for some people.
Whilst testing my app's ability to cope with documents that cause CFURLCreateFromFSRef to fail due to path length restrictions I thought I'd see how other stuff in the system copes with such files.
In short, the answer is appallingly, so I am thinking that maybe I really shouldn't care. From my own testing it seems that no-one would actually be able to work with such a document anyway. (FYI - my app doesn't create or edit any documents, it just works with them in other ways.)
E.g.
Finder
Once you drag something into a folder that makes its path too long, you can no longer drag it out again.
You can't use Open With as that calls down to LSCopyApplicationURLsForURL and the URL is duff. (Why no LSCopyApplicationURLsForRef ?)
Cocoa apps
You cannot open any such document or save a document to such a place. No user feedback apart from dimmed Open/Save buttons in Open/Save dialogs. Double-clicking them in the Finder does nothing.
Carbon apps
You can double-click them to open them, but attempting to use Nav Services to open or save them will crash the app whilst trying to update the Recent Documents:0 com.apple.CoreFoundation 0x90737b9c CFURLGetString + 52
1 com.apple.NavigationServices 0x930770a0 TBrowseDialog::SaveDialogPrefs() + 876
2 com.apple.NavigationServices 0x93076b28 TBrowseDialog::TerminateDialog() + 88
3 com.apple.NavigationServices 0x93076a90 _NavDialog::TerminateWithUserAction(unsigned long) + 72 Spotlight
Never finds such a file.
Classic apps
No problems at all :)
So given that I haven't heard of hoards [sic] of users storming Infinite Loop with pitch forks and burning sticks complaining about these problems I really do think that it is a moot point.
Any comments? |
Comments? Plenty. But it's more entertaining to let others comment. Note that the above report on 'Classic apps' is inevitably going to act as a kind of trigger - or a piece of cheese.
For those of you who don't know, *nix guys think it's a really good idea to represent file system entities as, of all things, strings. This is especially shocking, because *nix is written in C, and C's handling of strings is extremely deficient.
One quick indicator of such shoddy code is the presence of PATH_MAX, a constant #define'd to 1024 on Mac OS X. Programmers use PATH_MAX when they need to store a path and don't want to hassle with dynamic memory or variable length storage issues. (In my personal Neighborhood of Make-Believe, PATH_MAX is obliterated, and all code that subsequently breaks is thrown away.)
Mac OS X uses PATH_MAX in its BSD layer. Unfortunately the NeXT guys were also *nix guys, which means they also think path strings are the bee's knees. Thus Cocoa's file system entity representation is, sigh, NSString. Cocoa does an excellent job of re-exporting the BSD-level brokenness, as we'll see in a minute.
Perhaps you can see the trouble brewing. At the very bottom is the file system code, which is robust and well-structured. Then a sloppy layer of path strings is slathered on top of that. Then we build our programs on top of that sloppy layer. It's as if you're building a house on a granite foundation, but before you start you lay down a six-foot thick blanket of tofu. Kind of defeats the purpose.
Well, you don't have to use the tofu file system APIs. You can use Carbon's granite FSRef-based APIs, which offers [sic] high-fidelity file system entity routines. They're not path-based, and thus don't suffer from the inherent flaws of path strings.
You can file a bug against this if you want, but it will probably will be closed as duplicate and ignored. This bug is a design choice from 10.0, and I don't see Apple fixing it anytime soon. About the best we can hope for is that they patch up the Finder to allow dragging the file out again. |
Time to make a phone call.
Hello?
Dennis! Did we wake you?
Ah. Hi. No. I already had breakfast.
What was for breakfast?
A bottle of Thunderbird and a medley of Billy Gibbons solos. What's on your mind?
It's about these PATH_MAX things.
Ah. Yes. Sorry about that.
So you don't like them either?
[Inaudible.] No. Of course not. But I could never convince Thompson to abandon them.
Oh. Wow.
Yeah. Doug wouldn't have liked it much though.
Doug?
Yeah. Doug McIlroy. Our boss. He told us to make everything text.
But you would have abandoned path strings?
[Laughter.] Of course!
Really?
Sure!
And used what instead?
Well - have you ever played with a Mac?
You mean OS X?
No - the old Mac. Classic.
Not much. Generally succeeded in avoiding it.
You should give it a look. There's no PATH_MAX there.
What do they use instead?
Fuck if I know. But it works. Lots of colons though.
Yeah. Everybody's seen that.
And no relative paths.
OK.
So you don't really have any current working directory to speak of.
No.
Gets sort of paraplegic. Really fast.
Yes. Obviously.
Like that dumb mouse they had.
Right.
Then again I just don't know. [Inaudible.]
Know what?
Well it's like this. Doug said keep everything as strings.
Yep.
So machines could always communicate. ASCII strings.
Right.
And I don't know what those Macs used to identify and locate files but I assume it's binary.
Sure.
So?
So? So what?
[Laughter.] Well can you see what your URLs in your web browser location bar would look like today? |
See Also
Developers Workshop: Yo Yer Paths
|