1)
open() is called with flag O_CREAT|O_EXCL, and the name already exists in
form of a *symlink* which in turn points to a *non-existing* name.
I found the following behaviour on differerent machines:
Linux-2.0.27: -EPERM
SunOS 1.1.1: -EPERM
Solaris (SunOS-5.4): -EPERM
HP-UX 9.0: (OK, the new name is created)
I personally feel the HP-UX semantics is right, but does anybody know what
Posix (or other standards) say?
The problem is much deeper than this single example may suggest.
The differences between platforms become more elaborate if trailing
slashes in pathnames are added as an "independent" concept:
2)
Try the following on different platforms:
[0] rm -rf test test2
[1] ln -s test2 test
[2] mkdir test || mkdir test2
[3] rmdir test && mkdir test2
[4] rmdir test/
Now the rusults:
* cmd | HP-UX | SunOS | Solaris | Old Linux | New Linux |
* ----------------------------------------------------------------
* [2] | (OK) | EEXIST | EEXIST | EEXIST | (OK)
* [3] | ENOTDIR | ENOTDIR | ENOTDIR | ENOTDIR | ENOTDIR
* [4] | (OK) | EINVAL | ENOTDIR | ENOTDIR | (OK)
The last column is what I'm currently implementing in a patch that I have
to do for very different reasons, but I strumbled over the problems and
so I'm carrying out "side effects" that influence my original problem.
3)
rm -rf x y; touch y; ln -s y x; rm x/
Under HP-UX, this succeeds and removes the file y, not the symlink x!
Solaris and old Linux remove the symlink instead, and old SunOS
complains ENOTDIR.
I'd prefer the SunOS behaviour, because trailing slashes should *always*
lead to an error if the corresponding inode is not a directory.
However I'd suggest that if the last path component is a symlink, it
should be always followed if a trailing slash occurs, so the
"corresponding inode" can never be a symlink, IMHO.
4)
The following works on HP-UX and Solaris, by producing a symlink chain:
rm -rf x y z; mkdir z; ln -s z y; ln -s y x/
Under old SunOS, the following appears:
ln: x/: No such file or directory
Under current Linux, very strange things occur:
ln: cannot create symbolic link `x//y' to `y': No such file or directory
This is very probably a bug, but may be caused by the ln program
when checking for a directory target. I did no deeper investigation
of that. Generally speaking, when having a symlink *chain* (all *endpoints*
are symlinks, not nested inside the path), a trailing slash that occurs
somewhere in this chain and/or in the user-specified path, should be treated
as a specification of a directory, IMHO.
[The last aspect will have dramatic consequences for the current
implementation of the VFS, but this problem is not to be discussed here.
My questions are *only* for the *correct* *behaviour* that is desirable,
not more!]
Now, which behaviours are right? Please answer only if you have competent
thoughts on the *problem* and/or *know* what Posix says or you *know*
that Posix lets some of these questions open.
-- Thomas