5

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. http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_276);
  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.

4
  • 4
    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, 2010 at 12:18
  • 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, 2010 at 13:43
  • @DrFloyd: Right. Fixed. Apr 13, 2010 at 10:01
  • 1
    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, 2015 at 18:07

5 Answers 5

3
+100

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.
/dev
Contains /dev/console, /dev/null, and /dev/tty, described below.

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

/tmp
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:

/dev/null
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).
/dev/tty
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:

/dev/console
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.

2
  • 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, 2010 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. Jan 24, 2010 at 9:45
3

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.

2
  • +1 for an answer that made me look something up. POSIX forbids "/" and NUL in filenames. Cf. my questions postscript. Jan 18, 2010 at 13:05
  • What happens if you include the newline character or ASCII control codes in a file name? Mar 21, 2020 at 4:21
2

/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

1

"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.

6
  • Hehe, +1 for that last paragraph. There is an answer to any question, I guess. :-)
    – Arjan
    Jan 14, 2010 at 14:34
  • s/fails/cannot succeed/ Jan 14, 2010 at 20:27
  • 1
    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. Jan 14, 2010 at 20:30
  • -1: Completely misses the point of the question. Jan 18, 2010 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 -- superuser.com/faq)
    – Arjan
    Jan 18, 2010 at 13:56
0

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.

3
  • Every pathname that POSIX says is legal is accepted on all POSIX-compliant filesystems, by definition. It is these that I care about. Jan 18, 2010 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, 2010 at 14:13
  • Aha! No, I want pathnames that would work, except that other assumptions in POSIX prevent the files from existing Jan 18, 2010 at 15:10

You must log in to answer this question.

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