Distributions

Empty symlinks and full POSIX compliance

Symbolic links are a mechanism to make one pathname be an alias for another. One would think that there would be little value in an empty symbolic link — one where the destination pathname is the empty string — but that doesn't keep people from trying to create such links, an act that the Linux virtual filesystem layer does not allow. It turns out that its refusal to allow the creation of empty symbolic links puts Linux out of compliance with the POSIX standard. The real question, though, might be: how much does that really matter?

Pointing to the void

It turns out that many Unix-based systems will happily allow a command like:

    ln -s "" link-to-nothing

On a Linux system, though, that command will fail with a "No such file or directory" error. This is, as was pointed out in a bug report last January, a somewhat confusing message. If the empty string is replaced by the name of a nonexistent file, no such error results. In other words, for most cases, the lack of an existing file is not a concern. So it seems strange that Linux would gripe about "no such file" in the empty string case.

As part of the ensuing discussion, it turned out that the POSIX standard was not consistent with how empty symbolic links (that already exist in the filesystem) are handled in existing systems. Solaris systems will, when such a link is dereferenced, treat it as a link to the current directory; essentially, an empty link is treated as if it were "." instead. BSD systems respond differently: they take the position that no such file can exist and duly return the "no such file" error. Neither of those responses was compliant with POSIX, a problem which was only fixed in early May, when the standard was updated to allow either the Solaris or the BSD behavior. The result is a standard that explicitly says one cannot know how the system will resolve an empty symbolic link; they might work, or they might not.

How Linux handles an attempt to resolve an empty symbolic link that already exists within a filesystem is not well defined. Some of the work of link resolution is pushed down into filesystem-specific code, so the behavior may depend on which filesystem type is in use. It is hard to test because, as mentioned above, Linux does not allow the creation of empty symbolic links, so they can only come by way of a filesystem from another system. But, in general, an attempt to resolve an empty symbolic link can be expected to return a "No such file or directory" response.

The refusal to create an empty symbolic link, as it turns out, is contrary to how POSIX thinks the symlink() system call should work. The standard text says explicitly that the target string "shall be treated only as a character string and shall not be validated as a pathname." Empty strings are valid character strings, and the implementation is not allowed to care that they cannot be the name of a real file, so, by the standard, the creation of such a symbolic link should be allowed.

Back in January, Pádraig Brady posted a patch enabling the creation of empty symbolic links. The patches did not generate much interest at that time. He followed up in May after the standard had been updated; this time Al Viro expressed his feelings on the matter:

And that is pretty much where the discussion stopped.

Linux and POSIX compliance

That said, it would not be entirely surprising if such a patch were to make it into the kernel at some point. The cost of enabling the creation of empty symbolic links is essentially zero, and adding that capability would bring Linux a little closer to POSIX compliance. But true POSIX compliance, which is a function of both the kernel and the low-level libraries that sit above it, still seems like a distant goal for Linux distributions as a whole.

As a Unix-like system, Linux is not that far removed from compliance with the POSIX standard. Linux developers normally try to adhere to such standards when it makes sense to do so, but they generally feel no need to apply changes that, in their opinion, do not make technical sense just because a standard document calls for it. The reaction to the creation of empty symbolic links is a case in point. The value of closer adherence to POSIX is not seen as being high enough to justify the addition of a "feature" that seems nonsensical.

The value question is an interesting one. Getting certified to the point where one can use the POSIX trademark is a matter of passing the verification test suite, applying for certification, and handing over a relatively small amount of money as described in the fee schedule [PDF]. An enterprise Linux distributor wishing to claim POSIX compliance could almost certainly attain this certification in a relatively short period of time with an investment that would be far smaller than was required for, say, Common Criteria security certification. Carrying some non-mainline patches to the kernel and C library would likely be necessary, but enterprise distributors have generally shown little reluctance to do that when it suits their interests.

But there are no POSIX-certified Linux distributions on the market now. As far as your editor can tell, the only time a distribution has achieved that certification was when Linux-FT claimed it in 1995. That work was (or was not, depending on which side of the argument you listen to) acquired by Caldera shortly thereafter; Caldera, too, intended to achieve POSIX certification. That certification does not appear to have happened, and Caldera, of course, followed its own unhappy path to its doom. Since then, corporate interest in POSIX certification for Linux has been subdued, to say the least.

One can only conclude that the commercial value of a 100% certified POSIX-compliant distribution is not enough to justify even a relatively small level of effort. If distributors were losing business due to the lack of certification, they would be doing something about it. But, it seems, "almost POSIX" is good enough for users, especially in an era where Linux is the preferred platform for many applications.

POSIX still has its place; it sets the expectations for the low-level interface provided by the operating system and helps to ensure compatibility. But, increasingly, most current development work is outside of the scope of POSIX. The standard cannot hope to keep up with the changes being made to Linux at the kernel level and above. We live in a fast-changing world where, in many cases, "what does Linux do?" is the real standard. The developers who are busily pushing Linux forward have little time or patience for working toward complete POSIX compatibility when the interesting problems are elsewhere, so a fully POSIX-compliant distribution seems unlikely to show up in the near future.

Comments (27 posted)

Brief items

Distribution quotes of the week

-- Josselin Mouette

-- Enrico Zini

-- Michał Górny

Comments (7 posted)

Debian GNU/Hurd 2013 released

While it is not an official Debian release, the Debian GNU/Hurd team has announced the release of Debian GNU/Hurd 2013. GNU Hurd is a Unix-style kernel based on the Mach microkernel and Debian GNU/Hurd makes much of the Debian system available atop that kernel.

Comments (35 posted)

Mageia 3 released

The much-delayed Mageia 3 release is out. "We dedicate this release to the memory of Eugeni Dodonov, our friend, our colleague and a great inspiration to those he left behind. We miss his brilliance, his courtesy and his dedication." Changes include an RPM upgrade, the 3.8 kernel, availability of GRUB2 (but GRUB is still the default bootloader), and more. See the release notes for lots of details.

Comments (6 posted)

NetBSD 6.1

The NetBSD Project has announced NetBSD 6.1, the first feature update of the NetBSD 6 release branch. "It represents a selected subset of fixes deemed important for security or stability reasons, as well as new features and enhancements." See the changelog for details.

Comments (41 posted)

Pidora 18

Pidora is a Fedora remix for the Raspberry Pi. Pidora 18 has been released. "It is based on a brand new build of Fedora for the ARMv6 architecture with greater speed and includes packages from the Fedora 18 package set."

Full Story (comments: none)

Distribution News

Debian GNU/Linux

"Bits from Debian" editors delegation

DPL Lucas Nussbaum has appointed Ana Beatriz Guerrero López and Francesca Ciceri as Bits from Debian editors. "The Bits from Debian Editors oversee and maintain the official blog of the Debian project, "Bits from Debian"".

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

• DistroWatch Weekly, Issue 508 (May 20)
• Ubuntu Weekly Newsletter, Issue 317 (May 19)

Comments (none posted)

OpenMandriva Picks Name, Releases Alpha (OStatic)

OStatic covers recent news from OpenMandriva. "While the rest of Linuxdom was reading of the Debian 7.0 and Mageia 3 releases, the OpenMandriva gang have been hard at it trying to get their new distribution some attention. The OpenMandriva name was made official and an alpha was released into the wild."

Comments (none posted)

Tails 0.18 can install packages on the fly (The H)

The H takes a look at Tails, The Amnesiac Incognito Live System. "Existing Tails users are also strongly urged to upgrade to Tails 0.18; the team lists security vulnerabilities discovered in the previous 0.17.2 release to reinforce that recommendation. Another new feature in the Debian-based distribution is support of obfs3 bridges when using the Tor network. Obfuscation bridges make it harder for the ISP to know a user is using the Tor network by disguising the protocol in use; obfs3 is the latest version of the protocol replacing obfs2 which no longer works in China."

Comments (none posted)

Page editor: Rebecca Sobol
Next page: Development>>