From owner-freebsd-bugs@FreeBSD.ORG Mon Jan 23 09:00:23 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B79D16A41F for ; Mon, 23 Jan 2006 09:00:23 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B628543D4C for ; Mon, 23 Jan 2006 09:00:22 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0N90MOs077803 for ; Mon, 23 Jan 2006 09:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0N90Mh5077802; Mon, 23 Jan 2006 09:00:22 GMT (envelope-from gnats) Date: Mon, 23 Jan 2006 09:00:22 GMT Message-Id: <200601230900.k0N90Mh5077802@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: bin/92149: [patch] ln -f -s does not remove existing directory X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2006 09:00:23 -0000 The following reply was made to PR bin/92149; it has been noted by GNATS. From: Gleb Smirnoff To: Eugene Grosbein Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: bin/92149: [patch] ln -f -s does not remove existing directory Date: Mon, 23 Jan 2006 11:53:36 +0300 E> >Description: E> E> "ln -f -s" may be used to create a symlink to the file and E> the target file will be unlinked if it exists. E> E> However, ln will fail with 'Operation not permitted' message E> when target is a directory because unlink(2) does not remove E> empty directories. I think that the current behavior is standard, while suggested behavior is going to violate SUSv3. At least I understand the standard this way: If the destination path exists: 1. If the -f option is not specified, ln shall write a diagnostic message to standard error, do nothing more with the current source_file, and go on to any remaining source_files. 2. Actions shall be performed equivalent to the unlink() function defined in the System Interfaces volume of IEEE Std 1003.1-2001, called using destination as the path argument. If this fails for any reason, ln shall write a diagnostic message to standard error, do nothing more with the current source_file, and go on to any remaining source_files. http://www.opengroup.org/onlinepubs/000095399/utilities/ln.html -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE