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

The Open Brand -- Problem Reporting and Interpretations System

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

Report 0345 Actions

    Problem Report Number 0345
    Submitter's Classification Specification problem
    State Resolved
    Resolution Permanent Interpretation (PIN)
    Problem Resolution ID PIN.X.0061
    Raised 1998-05-29 08:00
    Updated 2003-03-13 08:00
    Published 1998-06-22 08:00
    Product Standard Network File System
    Certification Program The Open Brand certification program
    Test Suite VSX4+XNFS version 4.4.2
    Test Identification /tset/XNFS.prtl/proto/readlnk/T.readlnk 1
    Specification Protocols for X/Open Interworking: XNFS, Issue 4
    Location in Spec See Problem Text
    Problem Summary PIN4.061 We have been exchanging support request emails to further clearify this matter. First is the original text of our support request followed by the last response from X/Open below. We are requesting an ...
    Problem Text
    We have been exchanging support request emails to further clearify
    this matter. First is the original text of our support request followed
    by the last response from X/Open below.

    We are requesting an interpretation of the spec with respect to
    this issue.

    More specifically, an interpretation to the support response below:

    "I do not believe that this is a problem with the test suite, but"
    "rather a problem with the use of the test suite in an unsuitable"
    "environment."
    "I suggest that you request an interpretation on this issue in"
    "order to drive forward a resolution."


    A. Original support request text
    =================================
    The T.readlnk test #1 is generating a symbolic link that
    has a maximum symbolic path name of 1024 characters. We
    think that the test #1 should call pathconf() to determine the max
    length for maximum path, instead of hard coding a '1024'.

    We only support file names length 1023 in our file system type XFS.

    from:
    Open Group Technical Standard
    Protocols for Interworking: XNFS, Version 3W
    Document Number: C702
    ISBN: 1-85912-184-5

    Consistency of Limits

    A similar problem exists with other limits, such as the maximum number
    of characters in a filename, or the maximum number of hard links to a
    file. These limits may vary between different file systems, and Version
    2 of the NFS protocol does not provide a mechanism for this information
    to be made available to a client. The limits provided from a call to
    pathconf() need not accurately reflect the limit imposed by the
    server's file system. This may cause file access requests to be
    rejected by the server or for files to be inaccessible from the
    client.

    B. Last X/Open response to our rebuttals
    =========================================

    I think that we are wandering away from the basic issue here.
    Let me try to simplify this by coming back to the basic question, which
    as I understand it is:

    (1) Can an XNFS protocol call to NFSPROC_SYMLINK restrict the
    size of the symlinkargs.to field to less than 1024 bytes?

    (2) If this limitation is allowed, what return code is used to
    indicate that the call has not succeeded?

    On your system, when the symbolic link is stored on an XFS file
    system no more than 1023 bytes of data is stored as the content of the
    symbolic link and the return value on an attempt to store 1024 bytes is
    set to NFSERR_NAMETOOLONG.

    You state that this is a restriction of the XFS file system rather
    than in the NFS protocol. This raises the question as to whether the XFS
    file system imposes restrictions beyond the XSH base specification. I would
    also suggest that the XNFS specification treats the NFS server as a "black
    box" which must accept RPC requests and respond to them in the correct manner.
    In the case that the server implements NFS as a layer on top of a "local"
    file system, then that file system forms part of the "NFS server
    implementation".

    I agree that the test does not attempt to distinguish errors that
    are related to the protocol from those that are associated with the underlying
    file system. However, there is reasonable evidence that the XNFS specification
    expects any underlying file system to support certain capabilities in order
    that XNFS will function correctly. I would suggest that the storage of
    symbolic links of 1024 bytes in length is one of these capabilities.

    The references to error returns from the symlink() call are not
    relevant to this discussion since the ENAMETOOLONG (and almost all of the
    other errors) relate to the path2 argument of symlink() which equates to the
    symlinkargs.from field. Likewise the return code NFSERR_NAMETOOLONG from a
    call to NFSPROC_SYMLINK refers to an incorrect symlinkargs.from argument.
    I cannot agree with your argument that the NFSERR_NAMETOOLONG definition can
    refer to filename component within symlinkargs.to, the definition of this
    field states that "The server must consider it as a string with no internal
    structure". Since it is considered to be without structure it can hardly be
    broken onto filename components. I also note that the restriction of
    NFSERR_NAMETOOLONG to file names is correct since the symlinkargs.from
    argument consists of a file handle for a directory and a file name within
    that directory. The comparison with ENAMETOOLONG cannot be made at the
    path name level because the NFS protocol only deals in file name components.

    The only references to symlinkargs.to in the XNFS specification state
    that this data is "not interpreted by the server, only stored in the newly
    created file". Similarly, the symlink() specification states that "The
    contents of the symbolic link are the string pointed to by path1". Neither
    of these statements suggest that any limitation can be placed on content size
    at the point of storage. The only error condition that seems to apply to the
    storage of a symbolic link is NFSERR_NOSPC in XNFS and ENOSPC for symlink(),
    which does not seem to be applicable in this case.

    My conclusion is that your underlying file system may not be Unix
    compliant, in that it places a restriction on the size of the contents of a
    symbolic link and, possibly, returns an error condition specified in XSH for
    a different purpose. The underlying file system may be compliant if it were
    to impose this restriction and return an error condition not specified in XSH.
    I doubt if this problem will have been identified by the VSU test suite because
    the size of the contents of a symlink is unlimited. The use of a (possibly)
    non Unix compliant system as the server seems to be creating problems for the
    XNFS test suite.

    However, the test shows that in the cases where a 1024 byte
    symlinkargs.to field is used, the return value indicates that there is a
    problem with the path specified in the symlinkargs.from field. This seems,
    at least, misleading and possibly in contravention of the XNFS specification.
    I agree that the XNFS specification is less rigorous than the XSH specification
    with regard to error conditions, so it could be argued that this practice is
    acceptable. This would need to be approved by the XNET working group as a
    valid interpretation of the specification.

    I do not believe that this is a problem with the test suite, but
    rather a problem with the use of the test suite in an unsuitable environment.
    I suggest that you request an interpretation on this issue in order to drive
    forward a resolution.
    Test Output
    ************************************************************************
    /tset/XNFS.prtl/proto/readlnk/T.readlnk 1 Unresolved

    Test Description:
    If the server supports symbolic links:
    A successful call to NFSPROC_READLINK(fhandle) returns
    a status of NFS_OK and path set to the contents of the
    symbolic link referred to by fhandle.

    Test Information:
    nfsproc_symlink_2() returned incorrect status
    expected <0> actual <63>
    ************************************************************************

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    This should be forwarded for review by the XNET working group.

    Review Type Expert Group Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution No Resolution Given
    Review Conclusion
    There is a gray area in the specification. It is clear that:

    1) An NFS client should reject a symlink request if the link is longer
    than 1024 bytes.

    2) An NFS server should not send more that 1024 bytes in a readlink
    response.

    3) Notwithstanding (1) the NFS client OS may limit a symlink() call (and
    possibly the data returned by readlink()) to its own PATH_MAX.

    However, it is not clear whether

    4) An NFS server OS may limit a symlink() call to its own PATH_MAX.

    The test suite assumes that the OS server may not place such a limit.
    This assumption, although not unreasonable, is not specifically
    supported by the text of the specification. Accordingly, XNET
    finds that this request results from a grey area in the specification.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Permanent Interpretation (PIN)
    Review Conclusion
    A Permanent Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority