HomeAbout Us A-Z IndexSearch * Contact Us Register LoginPress Shop

The Open Brand -- Problem Reporting and Interpretations System


Problem Report 2585 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 2585.


Report 2585 Actions


    Problem Report Number 2585
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0287
    Raised 2012-12-17 11:19
    Updated 2012-12-23 05:41
    Published 2012-12-23 05:41
    Product Standard Commands and Utilities V2 (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSC version 5.3.4
    Test Identification POSIX.upe/uudecode/uudecode.ex 24
    Specification Commands and Utilities Issue 4 Version 2
    Location in Spec see Problem Text
    Problem Summary VSC5: uudecode returns nonzero if change mode fails.
    Problem Text We want to get a PIN for uudecode.ex {24}, We passed this test unit 10
    years before.

    But in the year 2006, our developers of shell had changed the
    implementation of the utility "uudecode". They thought "chmod" is a
    necessry part of "uudecode", if "chmod" fails, "uudecode" should return
    non-zero.

    There are two relative descriptions for "uudecode"

    (1)
    The mode bits of the created file will be set from the file access
    permission bits contained in the data;
    that is, other attributes of the mode, including the file mode creation
    mask (see umask), will not affect the file being produced.


    (2)
    EXIT STATUS
    The following exit values are returned:
    0 Successful completion.
    >0 An error occurred.

    UNIX95 standard does not specify the priority of these 2 rules.

    Currently our developers do not have time to fix it. So we try to apply
    a PIN for "uudecode.ex{24}", because the UNIX95 standard is unclear
    about this behavior.

    The SUSv4 and SUSv5 might explicitly stated that "if uudecode can't
    change the permissions it is not an error". We understand that if we
    certify to UNIX V7 in the future, we must change our implementation of
    "uudecode".



    Thank you!

    Test Output 10|0 /tset/POSIX.upe/uudecode/uudecode.ex 21:56:57|TC Start, scenario
    ref 1-0, ICs: {24}
    15|0 3.8 1|TCM Start
    400|0 24 1 21:57:00|IC Start
    200|0 24 21:57:00|TP Start
    520|0 24 83952222 1 1|Assertion #24 (A): Test of GA11 - the utility
    recreates files with correct attributes.
    520|0 24 83952222 2 1|Contents of _ga11_errout:
    520|0 24 83952222 2 2|Testing GA11 for directory
    520|0 24 83952222 2 3|Testing GA11 for regular file
    520|0 24 83952222 2 4|Failure: command returned nonzero status.
    220|0 24 1 21:57:05|FAIL
    410|0 24 1 21:57:05|IC End
    80|0 0 21:57:06|TC End, scenario ref 1-0
    900|21:57:06|TCC End

    Review Information

    Review Type SA Review
    Start Date 2012-12-17 11:19
    Last Updated 2012-12-23 05:40
    Completed 2012-12-23 05:40
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion The Austin Group's interpretation of the current text is that
    when the file is writable but its permissions cannot be changed,
    uudecode must overwrite the file but then exit with a non-zero
    status. This is acknowledged as a defect, since it does not
    match existing practice, and the group intend to make a change
    in a future version of the standard to require that failure to set the
    permissions is not treated as an error.

    It is recommended that a Permanent Interpretation be granted.

    Problem Reporting System Options:

     

    Back   


Contact the Certification Authority