PATH_MAX?

Following the Pied Piper down to the docks. From the forum.

Get It Try It

First have a look at this.

https://rixstep.com/2/2/20070714,00.shtml

Then have a look at this.

https://rixstep.com/2/2/20071006,00.shtml

Now up to date: I was able, on 10.14 and from the command line, to create a valid path of 14,081 bytes. [Yes you read that right.]

14,081 is not a magic number - that's just when I tired of the exercise. Note that I did this with Apple's Terminal.app which dutifully reported back my CWD following the command pwd, every time.

I was naturally puzzled by this and wrote to my two acquaintances at the PHS in Norway. The reply I got kept things off track for a while. The reply said there were no constraints in APFS.

That part is true.

But the constraint is not and can never be in the actual file system - the constraint is in the operating system.

Here are some excerpts from header files for 10.14. The results for earlier versions are the same.

1. From /Applications/Xcode.app/.../usr/include/sys/dirent.h:

/*
 * The dirent structure defines the format of directory entries.
 *
 * A directory entry has a struct dirent at the front of it, containing its
 * inode number, the length of the entry, and the length of the name
 * contained in the entry.  These are followed by the name padded to a 4
 * byte boundary with null bytes.  All names are guaranteed null terminated.
 * The maximum length of a name in a directory is MAXNAMLEN when 32-bit
 * ino_t is in effect; (MAXPATHLEN - 1) when 64-bit ino_t is in effect.
 */

#define __DARWIN_MAXPATHLEN	1024

#define __DARWIN_STRUCT_DIRENTRY { \
	__uint64_t  d_ino;      /* file number of entry */ \
	__uint64_t  d_seekoff;  /* seek offset (optional, used by servers) */ \
	__uint16_t  d_reclen;   /* length of this record */ \
	__uint16_t  d_namlen;   /* length of string in d_name */ \
	__uint8_t   d_type;     /* file type, see below */ \
	char      d_name[__DARWIN_MAXPATHLEN]; /* entry name (up to MAXPATHLEN bytes) */ \
}

2. From /Applications/Xcode.app/.../usr/include/sys/param.h:

/*
 * MAXPATHLEN defines the longest permissable path length after expanding
 * symbolic links. It is used to allocate a temporary buffer from the buffer
 * pool in which to do the name expansion, hence should be a power of two,
 * and must be less than or equal to MAXBSIZE.  MAXSYMLINKS defines the
 * maximum number of symbolic links that may be expanded in a path name.
 * It should be set high enough to allow all legitimate uses, but halt
 * infinite loops reasonably quickly.
 */
#define	MAXPATHLEN	PATH_MAX

PATH_MAX is set to 1024. This includes the terminating 0 byte. I tested this ad hoc by watching carefully in Xfile how Apple's services reacted when the path got too long - the Apple code just bottomed out, refused to respond.

I also noted the same behaviour on some 3rd party apps: the path gets too long, and they just refuse to respond.

I also dug up our old legacy builds. I could not run the ACP for 10.2 or 10.3 as those are PPC-only, but 10.4 I could run. 10.4 behaved correctly.

What am I talking about? A thing alluded to in the latest changelog.

There's something funky going on under the bonnet in 10.14, perhaps earlier versions too, and it's not us. The documented constraints as seen above prove that.

But somewhere - somewhere, somewhere - Apple code is screwing up. Again. Yes I know. And IMHO this is a grievous blunder on their part: what they seem to be doing is overunning buffers!

This puts us in a precarious state. I've added band-aid code to Xfile to prevent mishaps, but this is only temporary of course. macTag and Xscan would have to be completely refactored. But, as we see now, and based on the documented constraints of the system itself, this would be like following the Pied Piper down to the docks.

What to do for now? Good question. A full Unix path of 14,081 bytes is illegal. You create one like that - anything in excess of 1023 - and things are likely to go south.

PS. Someone may ask 'but why not report it to Apple?' That poor someone has no knowledge of how things work. Unfortunately.

Cheers.

PPS. Never suspected. Who would have suspected? Just created a path on 10.7 of 1781 bytes. So this issue goes at least as far back as 10.7 - was that ten years ago?

OK 8.

https://www.apple.com/newsroom/2011/07/20Mac-OS-X-Lion-Available-Today-From-the-Mac-App-Store/