Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268771AbUIGXrP (ORCPT ); Tue, 7 Sep 2004 19:47:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268775AbUIGXrP (ORCPT ); Tue, 7 Sep 2004 19:47:15 -0400 Received: from mx02.qsc.de ([213.148.130.14]:51623 "EHLO mx02.qsc.de") by vger.kernel.org with ESMTP id S268771AbUIGXrF (ORCPT ); Tue, 7 Sep 2004 19:47:05 -0400 Date: Wed, 08 Sep 2004 01:45:58 +0200 From: Gunnar Ritter Organization: Privat. To: Christer Weinigel Cc: Horst von Brand , , Linus Torvalds , Tonnerre , Spam , ReiserFS List , Hans Reiser , Pavel Machek , David Masover , , , Jamie Lokier , Christoph Hellwig , Alexander Lyamin aka FLX , Chris Wedgwood , Christer Weinigel Subject: Re: silent semantic changes with reiser4 Message-ID: <413E4836.nailFFM11WGWE@pluto.uni-freiburg.de> References: <200409070206.i8726vrG006493@localhost.localdomain> <413D4C18.6090501@slaphack.com> <1183150024.20040907143346@tnonline.net> <413DD5B4.nailC801GI4E2@pluto.uni-freiburg.de> <413E3280.nailEK92X8CU7@pluto.uni-freiburg.de> In-Reply-To: User-Agent: nail 11.7pre 9/8/04 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2897 Lines: 62 Christer Weinigel wrote: > Gunnar Ritter writes: > > Excuse me, but there's really nothing broken here with POSIX and cp. > > You're just making an insulting talk about a part of the specification > > which currently serves GNU/Linux and other Unix-like environments very > > well, and has done so for about twelve years now. > "Broken" in the sense "POSIX mandates something that users wouldn't > expect". Only if one breaks it by making extensions in an inappropriate way. This is not a fault of POSIX. POSIX usually allows a lot of sane ways to introduce extensions. There are usually valid interoperability arguments for behavior prescribed by POSIX. It is really not one of those standards where you want to ignore every second word because it is obviously nothing but committee nonsense. > > > or the environment variale POSIXLY_CORRECT is set. > > Cool, data loss depending upon an environment variable which is even > > currently used by many programs unaware of such results. This really > > sounds like good engineering to me. > How would you consider cp to cause "data loss" if it _besides_ copying > the normal stream _also_ copied any named streams or xattrs belonging > to the stream? You are reversing the argument. If additional streams are introduced inappropriately by extending the semantics of S_IFREG files, POSIX requires cp to lose the data. Your proposal would then make this loss of additional stream data dependent on an environment variable that is already in wide use. If it was set by accident, the data would be lost. Besides, copying xattrs is usually permitted (POSIX.1-2004, XCU cp): # If the implementation provides additional or alternate access control # mechanisms (see the Base Definitions volume of IEEE Std 1003.1-2001, # Section 4.4, File Access Permissions), their effect on copies of files # is implementation-defined. It is also permitted to add other S_IFXXX types and then let cp act in an implementation-defined manner on them (cf. my earlier message <413E40D1.nailFBI11XFML@pluto.uni-freiburg.de>). The 'standardized' data loss would only occur if the standardized type of regular file, S_IFREG, was abused. This would really not be a fault of POSIX. > Lots of GNU utilities already differ from POSIX mandated behaviour > because the authors of those utilities belive that the POSIX mandated > behaviour is confusing. Sure, but it is not the preferred method of adding features. In addition, most of the existing POSIXLY_CORRECT influences are nothing but cosmetical details in comparison to copying/not copying stream data. Gunnar - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/