On Sat, 16 Jun 2001, Warner Losh wrote:

> In message <[EMAIL PROTECTED]> "Steve O'Hara-Smith" writes:
> :     I would argue loud and long that changing that *would* be broken. There
> : is never a guarantee (or even an implication) that a symlink points to a
> : valid directory entry (think unmounted filesystems, NFS ...). I find it hard
> : to imagine why creation time should be special in that regard.
> And it would break /etc/malloc.conf!  I'd have to agree 100% here.

No, it (disallowing null symlinks, not disallowing symlinks to nonexistent
files!!!) wouldn't break /etc/malloc.conf.  "ln -fs '' /etc/malloc.conf"
would simply fail after unlinking /etc/malloc.conf.  There would then
be no /etc/malloc.conf, which gives exactly the same behaviour as when
/etc/malloc.conf is a null symlink.

BTW, even ln(1) doesn't understand null symlinks:

    root$ cd /tmp                       # a safe place to clobber
    root$ ln -fs aj /etc/malloc.conf    # my usual malloc.conf
    root$ ln -fs a  /etc/malloc.conf    # normal changes to it work
    root$ ln -fs '' /etc/malloc.conf    # change it to null (works)
    root$ ln -fs aj /etc/malloc.conf    # attempt to change it back
    root$ ls -l /etc/malloc.conf        # change didn't work:
    lrwxr-xr-x  1 root  wheel  0 Jun 17 22:15 /etc/malloc.conf -> 
    root$ ls -l /aj                     # change clobbered root dir:
    lrwxr-xr-x  1 root  wheel  2 Jun 17 22:31 /aj@ -> aj

So disallowing null symlinks would actually unbreak /etc/malloc.conf.

Further debugging shows that the main bug is in the kernel.
stat(2) on a null symlink bogusly succeeds and classifies the symlink
as a directory.  ln(1) just believes this so it rewrites
"ln -fs aj /etc/malloc.conf" to "ln -fs aj /etc/malloc.conf/aj".
The kernel then resolves /etc/malloc.conf/aj to /aj.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to