Date: Wed, 10 May 95 12:20:11 MDT From: terry@cs.weber.edu (Terry Lambert) To: Bernard.Steiner@Germany.EU.net Cc: freebsd-bugs@FreeBSD.org Subject: Re: strange symlinks Message-ID: <9505101820.AA26150@cs.weber.edu> In-Reply-To: <199505101040.MAA18416@qwerty.Germany.EU.net> from "Bernard.Steiner@Germany.EU.net" at May 10, 95 12:39:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > The next one may be a general 4.4 problem...
> > assumption: /tmp/foo does not exist, /tmp/bar is a symlink to /tmp/foo.
> > chdir("/tmp/bar") fails with ENOENT, but at the same time
> > mkdir("/tmp/bar", 0x777) fails with EEXIST.
>
> I think this is a generic result of the path component item evaluation
> order. I guess the only thing to say is that "according to the code,
> this is correct behaviour" 8-).
>
> Yeah. There's more to this, actually. If you do an open(O_CREAT)
> (on SunOS4.1.3; haven't got the FreeBSD box with me now) you get a normal open
> file that the symlink points to. IN the light of the mkdir, this is a wee bit
> inconsistent, isn't it ?
Depends.
A symlink is a directory entry reference, not a path reference with the
current code semantics. Arguably, either is legal under POSIX. I'd
prefer that it be consistent between files and directories, but there
isn't a requirement that it be.
If someone eventually adds variant symbolic links that can point to
directories, then the "fix" for this will just fall out, since the
path name parsing will have to treat symbolic link contents as normal
path components (which you could mkdir).
Is there something you have that depends on this behaviour right now?
Terry Lambert
terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505101820.AA26150>