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

The Open Brand -- Problem Reporting and Interpretations System


Problem Report 1010 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 1010.


Report 1010 Actions


    Problem Report Number 1010
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0525
    Raised 2001-10-01 08:00
    Updated 2003-03-13 08:00
    Published 2001-10-04 08:00
    Product Standard Commands and Utilities V3 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSC version 5.1.2
    Test Identification POSIX.cmd/mkfifo 23
    Problem Summary TSD4C.00243 The file mode pattern expected by the test is incorrect.
    Problem Text
    Tom,

    Thanks for reporting this VSC bug. Looks like there was a mix-up
    over which mode to use in the test, and the expected pattern got
    changed to correspond to the reported mode instead of the one that
    was actually used.

    I will change the expected pattern to 'Xprw[a-z]rw[A-Z-]rw[A-Z-]'
    in the next release (and change the reported mode from 654 to u=rwx).

    Regards,
    Geoff Clare.

    > DATE: 2001 May 4
    >
    > SUBMITTER: Tom Speer
    > ORGANIZATION: Compaq OpenVMS Engineering
    > SUBMITTER'S EMAIL ADDRESS: Tom.Speer@compaq.com
    > SUBMITTER'S PHONE NUMBER: 603-884-1315
    > SUBMITTER'S FAX NUMBER: 603-884-0189
    > SUBMITTER'S MAILING ADDRESS:
    > Compaq Computer Corp
    > 110 Spit Brook Road ZKO3-4/U14
    > Nashua, NH 03062-2698
    >
    > HARDWARE
    > MANUFACTURER: Compaq Alphaserver
    > MODEL/SERIES: Alphaserver-xx
    > CPU: Alpha Series 21x64
    > NUMBER OF CPUS: 1
    >
    > OPERATING SYSTEM: Compaq OpenVMS
    > OS VERSION ID: V7.2
    >
    >
    > SUBMITTER'S PRIORITY: Standard
    >
    >
    > VSC VERSION: 5.1.2
    > VSC SECTION: POSIX.cmd
    > VSC TEST CASE: mkfifo
    > VSC TEST PURPOSE: 23
    >
    >
    > REQUEST/PROBLEM DESCRIPTION:
    >
    >
    > 200|1 1 08:27:29|TP Start
    > 520|1 1 235046 1 1|Assertion #23 (A): When a single mode clause starts
    > with 'u'
    > 520|1 1 235046 1 2| <LC> and nonzero umask
    > 520|1 1 235046 1 11|Note: The behavior associated with this assertion is
    > curren
    > 520|1 1 235046 1 12| <LC> tly
    > 520|1 1 235046 1 13|the subject of an IEEE POSIX.2 interpretation
    > request, whic
    > 520|1 1 235046 1 14| <LC> h
    > 520|1 1 235046 1 15|allows an alternative behaviour where the umask is
    > applied.
    > 520|1 1 235046 1 16|Testing "-m 654" with umask u=rx,g=rx,o=rwx
    > 520|1 1 235046 1 17|Command failed: 'expr "Xprwxrw-rw-" :
    > 'Xprw[A-Z-]r-[a-z]r-[
    > 520|1 1 235046 1 18| <LC> A-Z-]' >/dev/null 2>&1'
    > 220|1 1 1 08:27:33|FAIL
    >
    > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
    >
    > We would like some clarification regarding the expected results for
    > POSIX.cmd/mkfifo tp23 under VSC 5.1.2. This test has undergone
    > revision since VSC 5.1.1.
    >
    > Both versions of this test issue the identical sequence of umask and
    > mkfifo commands:
    >
    > umask u=rx,g=rx,o=rwx
    >
    > mkfifo -m u=rwx tetmkfifo0231.tmp
    >
    > The resulting mode bits for the output file are then checked against
    > an expected pattern.
    >
    > In VSC 5.1.1, the result is checked against the following
    > pattern:
    >
    > expr "X$mode" : 'Xprw[a-z]r-[A-Z-]rw[A-Z-]' >/dev/null 2>&1
    >
    > I.e., the test expects a mode of 'prwxr--rw-'.
    >
    > In VSC 5.1.2, the expected pattern is:
    >
    > expr "X$mode" : 'Xprw[A-Z-]r-[a-z]r-[A-Z-]' >/dev/null 2>&1
    >
    > I.e., the test expects a mode of 'prw-r-xr--'.
    >
    > One might assume that the difference in expected results between 5.1.1
    > and 5.1.2 has to do with the standard's ambiguity regarding when (or
    > if) umask settings should be applied to the resulting mode, with 5.1.1
    > mkfifo tests assuming umask is generally applied, and 5.1.2 assuming
    > umask is generally not applied.
    >
    > Our implementation assumes that umask is not applied in cases where an
    > explicit '-m' mode value such as 'u=rwx' has been specified to mkfifo.
    > Thus our implementation yields the result 'prwxrw-rw-' for tp23.
    > However, even if the umask setting is required to affect the result in
    > this case, it is hard to see how the given umask value of 0220 can
    > produce the expected 5.1.2 result of 'prw-r-xr--' from an -m value of
    > u=rwx.
    >
    > One clue to this question may lie in the JrnlMsg comment in tp23 5.1.2
    > just before issuing the mkfifo command:
    >
    > JrnlMsg 'Testing "-m 654" with umask u=rx,g=rx,o=rwx'
    > mkfifo -m u=rwx tetmkfifo0231.tmp
    >
    > A mode value of 654 (rw-r-xr--) is not equivalent to the u=rwx value
    > actually used in the next line. But for an implementation which does
    > not apply umask, 'mkfifo -m 654 tetmkfifo0231.tmp' will in fact
    > produce the mode value expected by the 5.1.2 script. It looks like
    > the expected result pattern agrees with the comment's -m value rather
    > than the mode value actually used.
    >
    > Is the expected result for 5.1.2 correct? If so, what language in
    > the standard supports the result?
    >
    > Any clarification would be welcomed.
    >

    Test Output
    200|1 1 08:27:29|TP Start
    520|1 1 235046 1 1|Assertion #23 (A): When a single mode clause starts with 'u'
    520|1 1 235046 1 2| <LC> and nonzero umask
    520|1 1 235046 1 11|Note: The behavior associated with this assertion is curren
    520|1 1 235046 1 12| <LC> tly
    520|1 1 235046 1 13|the subject of an IEEE POSIX.2 interpretation request, whic
    520|1 1 235046 1 14| <LC> h
    520|1 1 235046 1 15|allows an alternative behaviour where the umask is applied.
    520|1 1 235046 1 16|Testing "-m 654" with umask u=rx,g=rx,o=rwx
    520|1 1 235046 1 17|Command failed: 'expr "Xprwxrw-rw-" : 'Xprw[A-Z-]r-[a-z]r-[
    520|1 1 235046 1 18| <LC> A-Z-]' >/dev/null 2>&1'
    220|1 1 1 08:27:33|FAIL

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    As can be seen from the quoted email above, this request relates
    to a bug previously reported to VSC Support for which a fix has
    been identified.

    A Test Suite Deficiency is recommended.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Test Suite Deficiency (TSD)
    Review Conclusion
    This is an agreed Test Suite Deficiency.

    Problem Reporting System Options:

     

    Back   


Contact the Certification Authority