Empty symlinks and full POSIX compliance

Posted May 23, 2013 8:48 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Empty symlinks and full POSIX compliance by ogj
Parent article: Empty symlinks and full POSIX compliance

Changes in standards like POSIX take years to materialize. And many features like cgroups or namespaces have about zero chance to be approved, because no other vendor can realistically implement them quickly enough.

Empty symlinks and full POSIX compliance

Posted May 23, 2013 17:35 UTC (Thu) by wahern (subscriber, #37304) [Link] (7 responses)

Changes to the specification of existing interfaces can occur quickly. You can file a bug report against the specification, discuss, and expect a resolution in a reasonable timeframe.

In fact, in this case the issue was reported in January of this year and resolved in a few months.

The Linux kernel team is unique in their indifference toward the standard. It's usually companies (Red Hat in particular, because of its stewardship of glibc) who "represent" Linux. The BSD teams have no problem keeping POSIX compliance as a goal while continuing to evolve their own proprietary interfaces.

Perhaps if Linux kernel developers were more engaged a more satisfactory outcome would have resulted.

Empty symlinks and full POSIX compliance

Posted May 23, 2013 17:44 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

What does the POSIX compatibility achieves? Most of POSIX interfaces are either braindead simple or totally broken.

Sure, reasonable compatibility with POSIX is required (for process control, sockets, etc.) but trying to conform to all of the requirements? Nah, not worth it.

Empty symlinks and full POSIX compliance

Posted May 23, 2013 20:43 UTC (Thu) by dlang (guest, #313) [Link] (5 responses)

> Most of POSIX interfaces are either braindead simple or totally broken.

Actually, most of the POSIX interfaces work just fine. You are using them all over the place without realizing it.

However, there are some POSIX standards that are broken or just plain 'odd'. These are mostly historical accidents.

You have to remember, POSIX was not a standard dreamed up by Ivory Tower folks, it was a standard created to document what is actually in use to limit/prevent fragmentation between implementations.

This does mean that POSIX is always going to lag what's implemented, because it requires that multiple people implement something before they will standardize it (specifically to avoid Ivory Tower type problems)

There is value in being POSIX compliant, but you get 99.999%+ of the value by being "almost" POSIX compliant the way Linux is.

Empty symlinks and full POSIX compliance

Posted May 23, 2013 21:31 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

There is value in being POSIX compliant, but you get 99.999%+ of the value by being "almost" POSIX compliant the way Linux is.

It seems to me that refusing to follow the POSIX behavior when it's really stupid, as Linux is doing by refusing to create symlinks named the empty string, probably gives you slightly more value than rigid adherence to the standard would.

Empty symlinks and full POSIX compliance

Posted May 23, 2013 22:37 UTC (Thu) by dlang (guest, #313) [Link]

In case it's not clear, I completely agree with you. I was just talking about the value to be gained by following POSIX at all (I was replying to a post effectively claiming that POSIX is completely irrelevant and should be ignored/scrapped)

Empty symlinks and full POSIX compliance

Posted Jun 2, 2013 0:40 UTC (Sun) by yeti-dn (guest, #46560) [Link] (2 responses)

Certainly it can be argued that the POSIX-specified behaviour is stupid. But the same holds for the Linux behaviour. Giving `no such file or directory' for a symlink target -- what is more odd and confusing than that?

So the question is not whether to change nice Linux behaviour to stupid POSIX behaviour, but whether to swap one kind of stupid behaviour for another. If one of them is standard-compliant it should be the clear winner.

Empty symlinks and full POSIX compliance

Posted Jun 3, 2013 8:53 UTC (Mon) by micka (subscriber, #38720) [Link]

I'm not sure I agree that a change TO a stupid behaviour is a good idea, event if the current state is a stupid behaviour and the next state is standard-compliant.

The change is just not worth it, and if you must have a stupid behaviour, it's better to keep the one you have.

It would be different to change to a *less* stupid behaviour (even non standard-compliant) like changing the 'no such file or directory' to 'symlink to empty name not allowed'. Not compliant but sure less stupid and confusing.

Empty symlinks and full POSIX compliance

Posted Jul 20, 2013 1:49 UTC (Sat) by kirv (guest, #89016) [Link]

Bingo. As the originator of this 'bug report', the reason I posted it was that the error message was confusing. Consider:

$ ln -s /no-such-file foo
$ ln -s "" bar
ln: creating symbolic link `bar' -> `': No such file or directory

Since the non-existence of the target file is not a problem, what 'file or directory' is being referred to?

I have no particular use in mind for empty symlink targets, and just ran into this case while working up some test scripts. I do have use for arbitrary strings in the system target, and would think it preferable to allow the empty string there just for consistency, but at least the error message should be meaningful.

The whole POSIX question is beyond me, but I don't think any special handling should be necessary for empty symlinks. Just let them resolve as they are, e.g., so maybe cat bar or ls bar would look like:

$ cat ""
cat: : No such file or directory
$ ls ""
ls: cannot access : No such file or directory