Date: Fri, 4 Jul 2003 13:40:18 -0700 (PDT) From: Wartan Hachaturow <wart@tepkom.ru> To: freebsd-standards@FreeBSD.org Subject: Re: standards/41576: POSIX compliance of ln(1) Message-ID: <200307042040.h64KeI4M094767@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR standards/41576; it has been noted by GNATS. From: Wartan Hachaturow <wart@tepkom.ru> To: Lukas Ertl <l.ertl@univie.ac.at> Cc: bug-followup@freebsd.org, tjr@freebsd.org Subject: Re: standards/41576: POSIX compliance of ln(1) Date: Sat, 5 Jul 2003 00:30:46 +0400 > cd /tmp > mkdir foo bar > ln -s foo bla ### now /tmp/bla symlinks to /tmp/foo > ln -sf bar bla ### replace /tmp/bla to point to /tmp/bar, doesn't work FreeBSD is perfectly SUSv3 (IEEE Std 1003.1, 2003)-compliant here. http://www.opengroup.org/onlinepubs/007904975/utilities/ln.html says that ln should use unlink() on destination in case of "-f" option used. And conformant implementation of unlink's ".. path argument shall not name a directory unless the process has appropriate privileges and the implementation supports using unlink() on directories". Moreover, later, in informational section we see: "APPLICATION USAGE Applications should use rmdir() to remove a directory." FreeBSD's ln uses unlink() and behaves correctly on regular files, and it should not work that way with directories. Bug may be closed, I guess, and ln(1) may be changed back. One thing that we may do is to make ln print a warning in case of -f on a directory, but I personally think it's not worth it. -- Regards, Wartan. "Computers are not intelligent. They only think they are."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307042040.h64KeI4M094767>