lkml.org 
[lkml]   [2004]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: silent semantic changes with reiser4
    Christer Weinigel <christer@weinigel.se> wrote:

    > Gunnar Ritter <Gunnar.Ritter@pluto.uni-freiburg.de> 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/

    \
     
     \ /
      Last update: 2005-03-22 14:06    [W:4.154 / U:0.192 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site