Is the middle dot (interpunct) accepted on modern filesystem like EXT4?
Matthew Harrington
Is using the middle dot (aka. interpunct) accepted in folder names on modern filesystems like EXT4? I mean this character:
Wikipedia mentions the following for EXT4:
Allowed characters in filenames: All bytes except NUL ('\0') and '/' and the special file names "." and ".." which are not forbidden but are always used for a respective special purpose.
So I guess the interpunct should be okay. I think for CLI the interpunct may be cumbersome to work with even though generating the symbol with CTRL+SHIFT+u 00b7 is easy. I will only use GUI file managers to access my folders and files.
1 Answer
You already quoted the answer to this question.
Filesystems only care what you put in the filename if it conflicts with some technical use of the character. Basically, filenames are binary blobs to the filesystem. The noted exceptions are:
- The
/character can't be in a filename because it is used to separate filenames in a path. (They can be in a pathname obviously.) - The
\0character can't be in a filename because unix uses C strings to represent filenames, and C strings are terminated by a\0. It might be more technically correct to say every filename internally has exactly one\0in it, at the end. But obviously, in a pathname, the only the pathname is terminated by the \0, and all but the last filename in a pathname would be terminated with/. - The only two special filenames are
.and..-- these are legal filenames, but you can't create, delete, rename, or otherwise manipulate them for writing. (These are used to represent the current directory and parent directory.)
This is true within the scope of traditional unix filesystems and the unix filesystem API. This says nothing about other applications. Special characters in filenames (especially spaces) are known to cause all kinds of heartburn and bugs in programs (like the shell and shell scripts) that expect to use spaces as word delimiters. (The shell supports multiple ways to escape spaces and potential spaces, but buggy shell scripts might not use those correctly.) Unicode characters are less likely to cause issues, but buggy programs not expecting binary non-ascii characters in filenames might break. And obviously, ambiguous unicode characters in filenames might break people. But this is out of the scope of the filesystem, which just doesn't care.
1