symlink/03.t: mark test failure as expected on XFS due to target limit

[disgoel]

The symlink/03.t test assumes that a symbolic link can hold a target path equal to PATH_MAX (4096 bytes). However, XFS has an internal limit for symlink targets (MAXPATHLEN or 1024 bytes), which is smaller than the VFS PATH_MAX.

When running this test on XFS, the creation of a 4096-byte symlink (Test 1) fails with ENAMETOOLONG. Consequently, the cleanup step (Test 2) fails with ENOENT because the symlink was never created.

not ok 1 - tried 'symlink pjdfstest_f388d099a86baece05bd60b3ffdec961', expected 0, got ENAMETOOLONG
not ok 2 - tried 'unlink pjdfstest_f388d099a86baece05bd60b3ffdec961', expected 0, got ENOENT

This commit uses the 'todo' mechanism to mark these specific failures as expected behavior when running on XFS, ensuring the test suite passes on XFS while strictly enforcing limits on filesystems that support larger targets (e.g., ext4, Btrfs).

Result on xfs

# prove -rv tests/symlink/03.t
tests/symlink/03.t ..
1..6
not ok 1 # TODO XFS symlink target limit (1024) is smaller than PATH_MAX
not ok 2 # TODO Cleanup fails because symlink creation failed on XFS
ok 3
ok 4
ok 5
ok 6
ok
All tests successful.
Files=1, Tests=6,  1 wallclock secs ( 0.04 usr  0.00 sys +  1.22 cusr  0.11 csys =  1.37 CPU)
Result: PASS

Result on ext4

# prove -rv /home/pjdfstest/tests/symlink/03.t
/home/pjdfstest/tests/symlink/03.t ..
1..6
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
ok
All tests successful.
Files=1, Tests=6,  1 wallclock secs ( 0.03 usr  0.00 sys +  1.21 cusr  0.11 csys =  1.35 CPU)
Result: PASS

[disgoel]

@ngie-eign can you please review

[ngie-eign]

@disgoel : is there a way to query the filesystem to see whether or not the limits are set, e.g., with getconf?

[disgoel]

@disgoel : is there a way to query the filesystem to see whether or not the limits are set, e.g., with getconf?

@ngie-eign I investigated using getconf/pathconf with _PC_SYMLINK_MAX as suggested. Unfortunately, this doesn't work for XFS because the filesystem doesn't expose its 1024-byte symlink limit through the pathconf interface - it returns 'unlimited' even though the limit exists.

The XFS symlink limit is an internal filesystem implementation detail (MAXPATHLEN in XFS code) that's not exposed through POSIX APIs.

# ./pjdfstest pathconf . _PC_SYMLINK_MAX
unlimited

# ln -s "$(python3 -c "print('a' * 1024)")" test
ln: failed to create symbolic link 'test' -> 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa': File name too long

[ngie-eign]

@disgoel : is there a way to query the filesystem to see whether or not the limits are set, e.g., with getconf?

@ngie-eign I investigated using getconf/pathconf with _PC_SYMLINK_MAX as suggested. Unfortunately, this doesn't work for XFS because the filesystem doesn't expose its 1024-byte symlink limit through the pathconf interface - it returns 'unlimited' even though the limit exists.

That's an XFS bug that deserves fixing then. As much as it would be nice to make the test suite pass on every single OS/filesystem combination, this is one of those instances where the bug in the filesystem needs to be addressed instead of adding a hack/workaround in the test suite.

The XFS symlink limit is an internal filesystem implementation detail (MAXPATHLEN in XFS code) that's not exposed through POSIX APIs.

[disgoel]

That's an XFS bug that deserves fixing then. As much as it would be nice to make the test suite pass on every single OS/filesystem combination, this is one of those instances where the bug in the filesystem needs to be addressed instead of adding a hack/workaround in the test suite.

Understood - I'll try to report/fix it upstream.

[ngie-eign]

Closing the PR based on previous discussion.