Re: Clarification on PyNFS Test Case Behavior for st_lookupp.testLink in Versions 4.0 and 4.1

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Jan 01, 2025 at 06:28:12AM +0000, Gaikwad, Shubham wrote:
> Hi Bruce/PyNFS team,
> I hope this email finds you well.

Thanks, yes, but I'm not actually maintaining pynfs anymore and I don't
remember who is....

> I am reaching out to seek clarification regarding the PyNFS test case
> 'st_lookupp.testLink' (flag: lookupp, code: LOOKP2a/LKPP1a) included
> in the PyNFS test suite for v4.0 and v4.1. Specifically, I would like
> to understand the expected behavior relating to the error codes for
> this test case.
> 
> In the PyNFS test suite for v4.0, the test case LOOKP2a (located at
> nfs4.0/servertests/st_lookupp.py::testLink) initially checked for the
> error code NFS4ERR_NOTDIR. Subsequently, an update was made to this
> test case to also expect NFS4ERR_SYMLINK in addition to NFS4ERR_NOTDIR
> [reference: git.linux-nfs.org Git - bfields/pynfs.git/commitdiff].
> However, in the PyNFS test suite for v4.1, the corresponding test case
> LKPP1a (located at nfs4.1/server41tests/st_lookupp.py::testLink)
> continues to check only for NFS4ERR_SYMLINK as the expected error
> code.
> 
> Given the discrepancy, should the test case for v4.1 (LKPP1a) be
> updated to also check for NFS4ERR_NOTDIR, similar to the modification
> made for the v4.0 test case (LOOKP2a)? Additionally, while the RFC
> 8881 section on the lookupp operation [reference: Section 18.14:
> Operation 16: LOOKUPP - Lookup Parent Directory] does not explicitly
> mention the error code NFS4ERR_SYMLINK, it is noted in Sections 15.2
> [reference: Operations and Their Valid Errors] and section 15.4
> [reference: Errors and the Operations That Use Them]. Therefore, would
> it be reasonable to update the test case LKPP1a to allow both
> NFS4ERR_SYMLINK and NFS4ERR_NOTDIR as valid error codes, ensuring the
> test case passes if either error code is received from the server?

Not sure!  In theory I guess 4.1 could be stricter about the error code
than 4.0.  Language for other operations (e.g. LOOKUP, 18.13.4) does
seem to prefer ERR_SYMLINK in the case of a symlink.  I think the Linux
client probably only uses LOOKUPP in the export code, where the choice
of error is unlikely to matter.

I'd guess it doesn't matter much.  What motivates the question?

--b.

> 
> Your insight on this matter would be greatly appreciated.
> 
> References: 1. git.linux-nfs.org Git - bfields/pynfs.git/commitdiff --
> https://git.linux-nfs.org/?p=bfields/pynfs.git;a=commitdiff;h=6044afcc8ab7deea1beb77be53956fc36713a5b3;hp=19e4c878f8538881af2b6e83672fb94d785aea33
> 2. Section 18.14: Operation 16: LOOKUPP - Lookup Parent Directory --
> https://www.rfc-editor.org/rfc/rfc8881.html#name-operation-16-lookupp-lookup
> 3. Operations and Their Valid Errors --
> https://www.rfc-editor.org/rfc/rfc8881.html#name-operations-and-their-valid-
> 4. Errors and the Operations That Use Them --
> https://www.rfc-editor.org/rfc/rfc8881.html#name-errors-and-the-operations-t
> 
> Best regards, Shubham Gaikwad