Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

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

Report 1390 Actions

    Problem Report Number 1390
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Test Suite Deficiency (TSD)
    Problem Resolution ID TSD.X.0672
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1996-08-16 08:00
    Product Standard Internationalised System Calls and Libraries Extended (UNIX 95)
    Certification Program The Open Brand certification program
    Test Suite VSU version 4.1.0
    Test Identification CAPIbase/utimes 14
    Problem Summary TSD4U.00145 This test may fail on implementations because it is possible for st_time to be one second greater than expected time.
    Problem Text
    This test case rarely fails but occasionally we have seen the failure
    in the journal above.

    A file is created and then a stat() call is issued to record the
    time (st_ctime) of the last file status change. This value is
    saved in a variable and then a sleep() call is issued for SLEEP_TIME
    seconds. A utimes() call is then issued with non-NULL arguments.
    Another stat() call is then issued and the new st_ctime is checked.

    It is this method of checking that I think has a problem.
    The author added the sleep time (in seconds) to the original
    st_ctime of the file found after its' creation. The test then
    tests that the new st_ctime after the utimes() is exactly equal
    in seconds to the original st_ctime + SLEEP_TIME.

    In most cases this will work but in some cases the values may be
    off by one second. It is possible if the test were executed and
    the sleep() occurred near the end of a second (where the
    microseconds were very high) that rounding to the nearest second
    might occur in the utimes() call. The specification seems to leave
    open the possibility that st_ctime would get rounded up to the
    nearest second, since it permits rounding for st_atime and st_mtime.

    More importantly,
    You cannot count on utimes() taking place in exactly the second
    that follows where the sleep() left off. It is conceivably
    possible that the sleep() could have ended near the end of a second
    and that utimes() didn't complete in the expected second but instead
    completed early in the second that follows the expected second.

    Thus the following technique for verifying utimes() has updated
    st_ctime is potentially unreliable:

    ---------------------------------------------------------------------
    if(fstat(fd,&stat_buf) == -1){
    uwerrno("fstat");
    return;
    }

    tet_infoline("TEST: utimes() marks st_ctime for update");
    if(c_time+SLEEP_TIME != stat_buf.st_ctime){
    ---------------------------------------------------------------------

    A more reasonable approach would be to ensure that the st_ctime
    was AT LEAST equal to the original st_ctime + SLEEP_TIME and not
    more than a full second greater than that sum.

    Also there is a missing tet_infoline() function call following the
    above test statement that if present would have displayed more
    information in the event of a failure.
    Note the two (2) sprintf() calls issued consecutively. The results
    of the first sprintf() call are lost because there is no
    intervening tet_infoline().
    Test Output
    400|2042 14 1 18:27:32|IC Start
    200|2042 14 18:27:32|TP Start
    520|2042 14 603783200 1 1|SPEC1170TESTSUITE CASE 14
    520|2042 14 603783200 1 2|A call to int utimes(const char *path, const s
    520|2042 14 603783200 1 3|timeval times[2]) shall mark the time of the l
    520|2042 14 603783200 1 4|status change, st_ctime, for update.
    520|2042 14 417660952 1 1|PREP: Set up temp file
    520|2042 14 417660952 1 2|PREP: Issue utimes() call
    520|2042 14 417660952 1 3|TEST: utimes() marks st_ctime for update
    520|2042 14 417660952 1 4|ERROR: st_time time not set.
    520|2042 14 417660952 1 5| Received 839716057
    220|2042 14 1 18:27:38|FAIL
    410|2042 14 1 18:27:38|IC End
    400|2042 15 1 18:27:38|IC Start

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    We agree this is a test suite deficiency in the test
    suite version(s) listed.

    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