Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Are there any legal paths in POSIX that cannot be associated with a file, regular or irregular? That is, for which test -e "$LEGITIMATEPOSIXPATHNAME" cannot succeed?

Clarification #1: pathnames

By "legal paths in POSIX", I mean ones that POSIX says are allowed, not ones that POSIX doesn't explicitly forbid. I've looked this up, and the are POSIX specification calls them character strings that:

  1. Use only characters from the portable filename character set [a-zA-Z0-9._-] (cf.;
  2. Do not begin with -; and
  3. Have length between 1 and NAME_MAX, a number unspecified for POSIX that is not less than 14.

POSIX also allows that filesystems will probably be more relaxed than this, but it forbids the characters NUL and / from appearing in filenames. Note that such a paradigmatically UNIX filename as lost+found isn't FPF, according to this def. There's another constant PATH_MAX, whose use needs no further explanation.

The ideal answer will use FPFs, but I'm interested in any example with filenames that POSIX doesn't expressly forbid.

Clarification #2: impossibility

Obviously, pathnames normally could be bound to a file. But UNIX semantics will tell you that there are special places that couldn't normally have arbitrary files created, like in the /dev directory. Are any such special places stipulated in POSIX? That is what the question is getting after.

share|improve this question
Hmmm, I was wondering if that title couldn't be more descriptive, but whatever I come up with seems to yield a contradiction in terms... – Arjan Jan 14 '10 at 12:18
much better title, thanks. – quack quixote Jan 18 '10 at 14:15
Just a note... it's not \ it's /. In Unix \ is a fine character to have in a file. /user/chuck/tom\mary the filename=tom\mary. – DrFloyd5 Apr 10 '10 at 13:43
@DrFloyd: Right. Fixed. – Charles Stewart Apr 13 '10 at 10:01
I like this question. It reminds me of "Der Mouse", when moving from VMS to UNIX, being annoyed because he could not find a way to create a filename with a slash or a null in it - where the slash was part of the filename within a directory, rather than a separator between directory and something in the directory. // The standard POSIX APIs do not produce an error on such filenames, they simply interpret the embedded special characters as either path separate or string terminator. – Krazy Glew Dec 22 '15 at 18:07
up vote 3 down vote accepted

Since the final question is whether there are special places that couldn't normally have a file, like in the /dev directory stipulated in POSIX, then the andswer is YES.

The complete list of pre-determined files and directories is given in chapter 10, POSIX Directory Structure and Devices, of the IEEE Open Group Base Specifications Issue 6:

The following directories shall exist on conforming systems and conforming applications shall make use of them only as described. Strictly conforming applications shall not assume the ability to create files in any of these directories, unless specified below.

The root directory.
Contains /dev/console, /dev/null, and /dev/tty, described below.

The following directory shall exist on conforming systems and shall be used as described:

A directory made available for applications that need a place to create temporary files. Applications shall be allowed to create files in this directory, but shall not assume that such files are preserved between invocations of the application.

The following files shall exist on conforming systems and shall be both readable and writable:

An infinite data source and data sink. Data written to /dev/null shall be discarded. Reads from /dev/null shall always return end-of-file (EOF).
In each process, a synonym for the controlling terminal associated with the process group of that process, if any. It is useful for programs or shell procedures that wish to be sure of writing messages to or reading data from the terminal no matter how output has been redirected. It can also be used for applications that demand the name of a file for output, when typed output is desired and it is tiresome to find out what terminal is currently in use.

The following file shall exist on conforming systems and need not be readable or writable:

The /dev/console file is a generic name given to the system console (see System Console). It is usually linked to an implementation-defined special file. It shall provide an interface to the system console conforming to the requirements of the Base Definitions volume of IEEE Std 1003.1-2001, Chapter 11, General Terminal Interface.

share|improve this answer
The point being, I take it, that the three device files in \dev aren't directories, so, for example, \dev\tty\impossible can't exist. That sounds right. I'll check the POSIX semantics of directories. – Charles Stewart Jan 22 '10 at 8:43
I assume that the term "files" also includes directories, so in your example a POSIX program cannot also assume that it can create a directory named "impossible". The terminology used is a bit confusing, and I assume the the authors didn't imagine that /dev could contain directories. – harrymc Jan 22 '10 at 10:27
/dev can and typically does contain directories: SunOS has had a fsfs mounted at /dev/fd for ages, and its copied by most modern UNIXes. But POSIX forbids a file from being both a character special and a directory, so there can't be anything under /dev/tty. So chosen: I have my answer. – Charles Stewart Jan 24 '10 at 9:45

Testing for a filename with the null character in it should always fail.

POSIX reserves '/' and null from filenames. This is sensible: one is the directory separator, and one is a string terminator. To support that point, Wikipedia says ext2, ext3, and ext4 allow all bytes in filenames except null and the forward slash. NTFS, whether or not in POSIX-compatibility mode, disallows little more than that; and FAT variants also disallow null. In theory, it really depends on the file system. But I wouldn't hold my breath trying to find a case where null finds its way into a filename.

share|improve this answer
+1 for an answer that made me look something up. POSIX forbids "/" and NUL in filenames. Cf. my questions postscript. – Charles Stewart Jan 18 '10 at 13:05

/dev/null/impossible cannot exist. This is because /dev/null must be a file, and so cannot be a directory.

Same for /dev/tty/impossible and /dev/console/impossible

share|improve this answer

"Legal path in POSIX" already means that it can point to a filesystem object (file, directory, symlink, etc).

On the second thought, some filesystems (such as FAT) have restrictions on allowed characters in filenames. So in my computer, ~/fs/phone/This:is*a?file|name.txt would be rejected by the vfat filesystem driver.

To answer the second question, test -e "$LEGITIMATEPOSIXPATHNAME" fails when the file does not exist, obviously.

share|improve this answer
Hehe, +1 for that last paragraph. There is an answer to any question, I guess. :-) – Arjan Jan 14 '10 at 14:34
s/fails/cannot succeed/ – Charles Stewart Jan 14 '10 at 20:27
I am not familiar with any *nix where /dev/fd/this-is-not-a-file could be a file, but IIUC, POSIX doesn't say it couldn't be a file. So being legal path in POSIX doesn't mean a POSIX-compliant OS must permit a file to be created there. – Charles Stewart Jan 14 '10 at 20:30
-1: Completely misses the point of the question. – Charles Stewart Jan 18 '10 at 9:45
@Charles, it kind of strikes me as odd that you're downvoting while I think your question was not clear at all to start with. (And still has a very bad title, which is not a question at all -- – Arjan Jan 18 '10 at 13:56

The test would fail if the file-name breaks the limitations of the local implementation of POSIX.

Every file-system in existence makes assumptions as regarding maximum lengths, directory recursion limits and more. So a POSIX name that's legal on one operating system might not be legal on another.

So my answer to the question is "Yes":
Even names that are legal when tested on one POSIX system, may be rejected by another, because of implementation restrictions.

share|improve this answer
Every pathname that POSIX says is legal is accepted on all POSIX-compliant filesystems, by definition. It is these that I care about. – Charles Stewart Jan 18 '10 at 13:36
Well, NAME_MAX and PATH_MAX are implementation-dependent. I think you're contradicting yourself when you ask (1) for unattainable POSIX file-names, and at the same time (2) accepted on all POSIX-compliant systems. By definition, acceptable file-names cannot be unattainable, and the least-common-denominator of all POSIX systems is always attainable on all of them. – harrymc Jan 18 '10 at 14:13
Aha! No, I want pathnames that would work, except that other assumptions in POSIX prevent the files from existing – Charles Stewart Jan 18 '10 at 15:10

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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