Date: Mon, 12 Jun 2017 15:31:12 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219943] The '-F' option of ln(1) does not work as expected. Message-ID: <bug-219943-8@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219943 Bug ID: 219943 Summary: The '-F' option of ln(1) does not work as expected. Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: shivanshrai84@gmail.com CC: jilles@FreeBSD.org Created attachment 183435 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183435&action=edit Log file generated from executing `truss -o ln.log ln -sF A B` I was trying to make a kyua based test for the '-F' option of ln(1). Steps to reproduce - This was the command which I ran successfully - ``` mkdir A B truss -o ln.log ln -sF A B # '-f' is assumed to be present by default ``` Actual results - It so happens here that even though the target directory B exists, neither unlink nor rmdir is being called [ideally rmdir should be called as specified in src/bin/ln/ln.c (line 307)]. The output of the above command is that B contains a broken symbolic link A to A. I used truss(1) to trace the system calls when executing the above command and have attached the log file. As it can be seen in the log file, the rmdir system call is missing. Expected results - I think the expected behavior should be that directory B is deleted and a new symbolic link B is made to A. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219943-8>