I seems like it is possible to create filenames in unix with just about any valid character.

touch \; &&
touch \\ &&
touch \" &&
touch $'\n' &&
touch $'\t' &&
touch $'\v' &&
touch $'\23' &&
touch $'\13' &&
echo "DONE!"

The only characters I have found that does not work are / and NUL:

touch /
touch $'\0'

Are there any other characters that are invalid or impossible to use in filenames?

  • Related: Understanding Unix file name encoding
    – Marco
    Sep 17 '15 at 13:01
  • 1
    Only 0x00 and 0x2f are not allowed, everything else can be used from the kernel's perspective. That doesn't mean that all applications or file systems can deal with “funny” characters.
    – Marco
    Sep 17 '15 at 13:03
  • see also: unix.stackexchange.com/a/155860/117549
    – Jeff Schaller
    Sep 17 '15 at 13:24
  • At VFS level, only Nul is a forbidden character. A NFSclient may create a pathname component that contrains a /. Future POSIX versions may forbid characters 0x00..0x1F.
    – schily
    Sep 17 '15 at 13:31
  • The question doesn’t say a single word about Linux, but high-rep users closed it as a duplicate anyway. Sep 17 '15 at 15:29

The answer is: In Unix-like systems, file names are composed of bytes, not characters. At least from the perspective of the kernel and its APIs.

A Unix-like kernel is normally neutral about any byte value but \000 (ASCII: NUL) and \057 (ASCII: slash). In Linux, there are no other restrictions at the filesystem layer, but certain FS drivers and their modes lead to the rejection of some names, usually due to the impossibility of translation. For example, one can’t create a filename with invalid UTF-8 on anything mounted with -o iocharset=utf8 (e. g. types cifs or vfat). None of DOS/Windows-compatible FSes will allow you to make \134 (ASCII: backslash) a part of a name. Or the msdos type will apply DOS restrictions concerning 8.3 names.

Ext3/ext4 isn’t known to have restrictions but aforementioned \000 and \057.

  • 1
    also, a filename has to contain at least one character.
    – Boris
    Dec 30 '20 at 9:27
  • There's also the fact that case-insensitive filesystems, like msdos and its ilk, will have problems with any filenames matching already existing files with different case, when there would otherwise be no conflict. Not exactly a character-based restriction, but is a consequence of character-based rules.
    – ddawson
    Jul 20 '21 at 19:48

Not the answer you're looking for? Browse other questions tagged or ask your own question.