Limit of File-Path in OSX 10.13+

Question

Level 1

8 points

Limit of File-Path in OSX 10.13+

I just stumbled on a rather odd issue: it seems there is a limit of 1023 characters for filepaths (including path delimiter / or :)

/Users/as/Desktop/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/123456789/12345

if going to the maximum allowed length of file/folder names (255chrs) that means we could only have a folder with 3 subfolders on the desktop!

/Users/as/Desktop/123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345/123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345/123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345/12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456/

is there any way around that?!

in deeply structured projects we actually hit the limits!

also it becomes clear that OSX' interface is not prepared to handle what is allowed '-(

MacBook Pro 15", macOS 10.13

Posted on Apr 1, 2019 11:18 PM

Reply

Answer 1

Best reply

BobHarris

Level 9

52,949 points

Apr 2, 2019 5:30 PM in response to factors

OK, I just check

Yes, macOS is 1024

Linux 4096

Solaris 1024

AIX 1024

Memory says Tru64 UNIX was 4096, but it has been 14 years since I worked on the AdvFS file system code.

I think my comments about 4096 comes from working on Linux file system code so much.

Reply

Answer 2

Apr 2, 2019 2:44 AM in response to factors

I don't know if it is possible to change or override this limit but I can confirm the limit still applies even in Mojave on an APFS boot drive.

You can see what the limits are for individual file names and the entire path name using the following two commands.

getconf NAME_MAX /
getconf PATH_MAX /

Linux as a comparison has a PATH_MAX of 4096.

You could consider filing an enhancement request with Apple.

Reply

Answer 3

BobHarris

Level 9

52,949 points

Apr 2, 2019 6:31 AM in response to factors

MAX_PATH of 4096 and MAX_NAME of 255 in Unix environments is very common for the file system.

If an app, program or utility has a 1023 limit, then it is something in that app, utility or program that is inflicting the limit.

In a shell it is often possible to incrementally cd down to a deeper depth, as the MAX_PATH applies to the string handed to the file system to parse. But a relative path is parsed by starting with the current working directory's already open vnode (internal file system structure), so if you do something like:

cd /a/long/path/to/stage/1/dir

cd ./next/stage/of/the/long/path

cd ./the/3rd/stage/of/the/log/path

cd ./etc

you can sometimes navigate do extremely deep depths.

HOWEVER, sometimes the shell attempts to keep you in line, and I do not know what the default 'bash' shell does in this case, but I've used shells that allow me to navigate down really REALLY deep, which of course I did just for fun.

PS. I have been working on file system development (other companies) since the mid-90's

Reply