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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0437 Actions

    Problem Report Number 0437
    Submitter's Classification Specification problem
    State Resolved
    Resolution Rejected (REJ)
    Problem Resolution ID REJ.X.0056
    Raised 1994-04-18 08:00
    Updated 2003-03-13 08:00
    Published null
    Product Standard Network File System
    Certification Program The Open Brand certification program
    Test Suite VSX4+XNFS version 4.3.3
    Test Identification POSIX.os/files/rename 8
    Problem Summary PG4R.056 read on unlinked file returns -1 expected 84 and the errno set to 52 (ESTALE) This test case creates two files (i.e A and B). A is of 0 length and B has some data written to it. The testcase closes fi...
    Problem Text

    read on unlinked file returns -1 expected 84 and the errno set to 52 (ESTALE)

    This test case creates two files (i.e A and B). A is of 0 length and
    B has some data written to it. The testcase closes file A but keeps
    file B open. The test then renames file A to file B. At that point, the
    NFS file handle to the old file B is nolonger valid so an attempt to access
    the old file B is denied with ESTALE.

    The XNFS specification Section A.8 states the following:

    "If a file on the server is open by a process running on a client, and
    the file is deleted by the sam or a different process on that client,
    the client will rename the file to a temporary file. Any process that
    has this file open can continue using it. When the last proces on the
    client to have this file open closes it, the client issues a request to
    the server to delete the file."

    It is the perception that most current NFS implementations will handle
    the case where a direct remove of an open file will result in a rename
    by the NFS client. However it is believed that most NFS
    implementations will not handle the case where the file being removed
    is a target of a rename operation. In this case the client will do
    the rename without checking to see if the target file is open on the
    client. This is certainly the case in our implementation and has
    been. It is our request that the specification be changed so that it
    is clear that the NFS client is required to do a rename only in the
    case where a file is being removed directly by a remove operation and
    not indirectly by a rename operation. The basis for this is that
    there should not be any reliance for this behavior since it is not
    currently implemented in the industry.
    Test Output
    10|0 /tset/POSIX.os/files/rename/T.rename 07:34:20|TC Start, scenario ref 3-1,ICs {8}
    15|0 2.0b 1|TCM Start
    400|0 8 1 07:34:20|IC Start
    200|0 8 07:34:20|TP Start
    520|0 8 00008716 1 1|read() on unlinked file returned -1, expected 84
    520|0 8 00008716 1 2|errno was set to 52 (ESTALE)
    220|0 8 1 07:34:21|FAIL
    410|0 8 1 07:34:21|IC End
    80|0 0 07:34:21|TC End
    10|0 /tset/POSIX.os/files/rename/T.rename 07:34:20|TC Start, scenario ref 3-1,ICs {8}

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    No other users of the XNFS test sute have reported this problem, though
    it may exist on other implementations.

    The specification seems clear in this area and it is difficult to recommend
    a permanent interpretation without evidence that the XNFS specification
    contradicts common practice.

    This request should be forwarded to the interpretations group in order to
    establish whether the specification does or does not align with the behaviour
    currently exhibited by a substantial body of implementations.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Rejected (REJ)
    Review Conclusion
    This request is refused.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority