What is the maximum filename character length of files in OS X?

Of secondary importance is whether some characters are allowed/disallowed in addition to any overall length restrictions.

  • Assuming the HFS+ file system? – vcsjones Mar 24 '13 at 20:33

From the font of all knowledge, the maximum file name size in the default HFS+ file system is 255 UTF-16 encoding units, so basically 255 characters. Technically, any unicode character can be used, but this may be practically limited by the application you are using - for example, the / character is used to delineate directories in pathnames, so you may not be allowed to name a single file stuff/things.txt, as this means "the file things.txt in the stuff directory" to the operating system. There are ways of "escaping" characters like / in filenames, but for general use it's discouraged.

  • 1
    That with the / is not true (10.6 here). What you can't use is : (old HFS separator), at least in the Finder. Funny thing is that / is represented as : at the shell level. Another strange limitation is that the path length is limited by 1024 bytes or UTF-8 chars, not sure which. This isn't enforced by Finder and can lead to strange behaviour. – Percival Ulysses Mar 24 '13 at 21:11
  • @PercivalUlysses You are correct : is forbidden on HFS and HFS+ but most UNIX folk are used to automagic substitution of / for : and vice versa and don't realize HFS's internal storage uses : to separate directories from file names. – bmike Mar 24 '13 at 21:13
  • @bmike Yeah :) Do you know anything about this 1024 character limit for paths? On 10.6, this behaviour is documented in the system header files, and there is PATH_MAX variable. Still so on later systems? – Percival Ulysses Mar 24 '13 at 21:22
  • 1
    @PercivalUlysses Yes - on Mountain Lion I was able to make a directory path 1037 characters deep and plop a file and spotlight, finder aren't happy to navigate to, locate or open that file in Text Edit until I move it up one folder (where the path is 996 long) and everything works as expected. Also pathchk -p is handy for running these sort of portability checks. – bmike Mar 24 '13 at 21:38
  • 1
    I tested the following: touch 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 works fine. But touch 12345678901234567890....6 with one more character throws: File name too long. FYI touch just creates an empty file, or actually sets the existing file's time_modified to now. – xanderiel Jan 5 '18 at 17:27

Yes - you should keep file names to 255 characters but paths can be longer but not as long as some other unix allows.

The desktop OS X supports ten major filesystems (HFS, HFS Plus, UFS, WebDAV, UDF, FAT, SMB/CIFS, AFP, NFS, and FTP) with several variants of some of these. See table 1 at developer.apple.com's article below for details:

The system default filesystem, HFS plus supports filenames of 255 UTF-16 encoding units and the only reserved character is : which is used internally to denote a directory change as opposed to / which normally is reserved to signify a directory change rather than belonging to the name of the file. (ok - I believe 0x00, the null character also is forbidden in HFS+)

By convention, software should use file handles and are responsible for allocating enough space to contain an arbitrarily long file path if it doesn't use standard API for navigating the filesystem structure to locate a 255 length filename.

  • touch : and mkdir : work though – Stefan Dragnev Sep 5 '18 at 12:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .