pjd / pjdfstest Goto Github PK

Linux has had posix_fallocate(2) for some time. We should probably enable the tests/fix as necessary.

When building for i386 the format specifier when printing a ssize_t is wrong and causes the build to fail:

pjdfstest.c: In function ‘call_syscall’:
pjdfstest.c:1164:28: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘ssize_t’ {aka ‘int’} [-Werror=format=]
 1164 |    fprintf(stderr, "read %ld bytes\n", r);
      |                          ~~^           ~
      |                            |           |
      |                            long int    ssize_t {aka int}
      |                          %d

I would like to exclude file types that are not interesting to network file systems, e.g., block and char. I could add an array with all types to misc.sh which the environment would override. This would require doing some math in all the test plans, e.g., echo "1..203" becomes something like echo "1..$((${#DEVICE_TYPES[@]} * 7))". Is there a better approach to this than doing a bunch of arithmetic? I see some existing feature detecting code like:

if supported lchmod; then
        echo "1..203"
else
        echo "1..119"
fi

The create_file help command uses lchmod if the user specifies a file mode. However, none of the tests that use it have require lchmod. The best solution would be to globally replace lchmod with fchmodat, which is standardized by POSIX.

See full logs in https://github.com/juicedata/pjdfstest/runs/311551283

The failed cases are

not ok 12 - tried '-u 65534 -g 65534 rename pjdfstest_507cd353da4e6a94fcfa5a1848bfa1ef/pjdfstest_0faa6971e8b5933aaeb12abe3bfd8a97 pjdfstest_af492257fc817a5ad1bf72341e365119/pjdfstest_390caa9aa7e09d814f7d5b8133bef9f1', expected 0, got EACCES
8378
not ok 13 - tried 'unlink pjdfstest_af492257fc817a5ad1bf72341e365119/pjdfstest_390caa9aa7e09d814f7d5b8133bef9f1', expected 0, got ENOENT
8379
not ok 14 - tried 'unlink pjdfstest_507cd353da4e6a94fcfa5a1848bfa1ef/pjdfstest_0faa6971e8b5933aaeb12abe3bfd8a97', expected ENOENT, got 0

Most of the files in tests/ftruncate/ actually test truncate, not ftruncate. They appear to have been copied exactly from tests/truncate/ . The only exceptions are 00.t and 13.t. This error predates the git conversion.

I see tests 1 & 2 in symlink/03.t fail on ext4 file systems on two different distributions / kernels:

• openSUSE Leap 42.3 / Linux 4.4.103-36-default x86_64
• Ubuntu 16.4.03 LTS / Linux 4.10.0-42-generic x86_64

The output looks as follows:

1..6
not ok 1 - tried 'symlink 8c3393ecb2a669e63f2311d3bd1733a769d960c727dac9f7cdc0518fc77b0c63a9c566d3d5fe9bedfae035235608b85de179aede4dc9ef29c4538d4547a63c4/c98090877ea9e99900bd9b575360f3f3ed29ef0536691f4487a9b6dad80039010a6fdfddde4d47ba07539a95bb26ddc3644e7e788b16bd56a900237834ed95c/b580f8f8d4123dbf2aac4d55aaec0007cd5b11e6f07169e11fcee13c6677f9ea5088dd38a019eb0fa0f78fe26fc27b79c8a9eb3039580407c23e2d418f67ac2/38b2f484e1712a33138304ded70675dc1ee1127198a99e716087c2f2b349ec73f216ace4156253b79d4378472638ffb44c38e6ed9f70f88de720f09eee75d91/e0fb67e85f5461a5f57fc3fa5775fac66a75d24032f04d1fd8829f5cf019d2ea8cc845a51bd8f039fe566332233b719f8915bd7adc2f4cae054b18015491021/ff278ca4536a0d307ec0a20cf6405b5d2eb9471e7e1f8d980c38bcec5b9d2a89e785084e6b8f1ffe2e7e172b0b460f8c35127771b83100a3daab8992f5267af/c793a3258a23fde2c72b847faa24e7c5755728da1ddebcdafa6f866b37ac02f35c509f88a8169d195ddf533ea013a7dabfc0172e9d9339c039ce96c52228611/d28f37b47a3f8aff33bd854d43977f345f305a6dce271fe84f48aaf67df050f394faa3d6b96e23bb08d9fbe9b6853281e6821bfc6dbc3a536460454a4081df5/0dbd49325941f8e22966a08bdce5ff5c26cd545fe3f05e77fbe4fce6fa18e70423712c0e8ec8fc9d5c32b1e852358d034bcd774ccad17282ae6e2b3f6242a3b/062c3c72ecb3674edc722b9f43b00b650336118cf93301c99f73a56e9eba410f8839eceb2142f0689061fa04a322904b2094b1e1ad8b0ab5dcf286a81b369fc/f5ee3045cff41c71f9e8e17dec9de6d308b1a41c7c09a2ab894633d9f0a5e375df9c4bbf82aa4030a46aced1204f807d1c21ca48bcb290eee18cbd1590fec5c/96d9f673a0c574d0dae5ef10eec35ab999cc81007fa1a3f3c77d830c955cf6318806631c6a25c1121b93f1791f7746f851917b7356a165a2fb2c0ba632fec5e/b78171c2e9cbebffba9ac2bb274541029a92e7b3772388230765fafa3b2857f40b7a65100fa382759f66ccec69a7881e112dfb41ce3d1044bb66f52a6ada3ec/033848915fe4ab01e770dc3c627f67b08e9d2cafab557835174b0fe2bace83a025556a4a93ee291c3e7b14568fdd0ff7e127c944e14a735c4208aef17083a58/c123e653f0a6a8f8be21d8af19d8f07d9d2b88b7cb8617d75a70e56cb3a0d56e573e242e9c06438df4dc4eca13006643704967c9a66f8a5714257a863ce227b/d59c110b891221028f31eddfcec8240cee92808e90f7dfa304b20c6fbfaddc2382bfae959bbab0f0213bc90f110a99ac37582df29621d2b295834a0ee1bf629/71f908c369b29b8addf781e5070ccb61983238c7002fdffb9a402fbcc5df1acf4d5dfdb974555b0a61df9ae34f1299b4ed7f6da7bb628926f20e4198efb8899/16218ba4328c7386a4d9fcc21dc38619babec0651494c0f267972ee9781335530dde150fed88285d28e09569e0abfa7e4acc0a6399f639c886d847877d89a9b/f41b08283928d22948aacddd584f726328ecc4273b8ad27938cf37e2ad072ddcbc1a0e9f66814745d9ee34e1f0299458f5e39ecb64762b751446282fea48e8d/c4210ca57e10570a98e048985c447396d2a910321731781d08c52a13400a9966a11e449f91984111b98a3d4fb732215a0e918971ba818bf3fd5427a7a7326d4/cb6880ebd00d2bdbc49b9fb22fb21591663e210aad8a4436d8ec38611ebf41bcda74815f5e2f394c2e692fd352e8d8410b1c6272789274462ca8dd70bb950ec/88f22ab7776991b406ded8da27288f1e10bdd25e03711ff6d7d5194f9d7b1d9a498edad864e6964bd3650de2aa778b85d512221c6ca006acf6a0dd99db8d5d2/8e4581b6764504181a52d2e3620c413ccdae6f0bb74b830e3552730f8e00d3ec79d645884abf0eb32f5ee2023232392f00566e7e7e2f52f4a739872cfedb341/375554af7b64a34009c23a601be444856fd637115324de90d1fb9cb3077a8be764434af8e3bf71c04e47779733bb8f6fc54491cd126f795751b3b3ebc9bd6c6/64fbddd4abfe4f337fab5fad93849a0f9dbc1b483d344698f258f2a88cb3271ef176d7b4bf2d9208f1fa4dd63375a329c7dce4f229f65732f9bd48ed1441084/edc6ff1c247ea26dbc8196c1bf03ef91d4b161eafc793960869cd3b0554a000c128f4530130b276dd11b9447cf77599dcfcd386b862b0b9d41306e59d168538/54b62df2dc4c07f143f6ba943be094419ea516a24a4449cfab65805b82f2b480903bb589919c53b85493fd99fc0ed0fa0251e3678484128410c241fe01b7074/c361fc4d819714ef241aec91ed439886d8af28278f4fe888f8ef4ce13f4068491f04db6417f7bb909b2c71da9478ead4f5ae5b63b1d297756be8f8fb665b7a0/e27891a3afca9348d65c194ea8b2985e0aee4e4048e4418b8dbc2df1cdd531009e4b1928b01c646beb80375cfdcff5324adbdd3b293d0dc8cbfcc3bc186dee8/a9a73da1951a76e446bdb89084aed99f016c1af3fe9874015123eeafcd59159cfd01d8057d31e44a77d02f4c9b39d78b8742ad140611c2fafc5b8e6972ccf51/b6ba7e498f168859496d601fdbab243b50e646febf957b6743618811ae1317c0eda0ef7394712a4ecef2a5b30bee76fe490d2da199059660b6ea0ccadb567f8/
44f4517205b7b6e21a9cc55e2b379e2c112d0e407153d367bffb5d1bb9941522b6a6b251aa2ff91453322ec7c65a86329f4ecb16acdb4fe4d42673f69da3e8b pjdfstest_1ed95816e0eb09f8b38de6019ae5675b', expected 0, got ENAMETOOLONG
not ok 2 - tried 'unlink pjdfstest_1ed95816e0eb09f8b38de6019ae5675b', expected 0, got ENOENT
ok 3
ok 4
ok 5
ok 6

The strange thing is, the tests do NOT fail when running on Travis CI (sudo-enabled virtual machine, Ubuntu 14.04 LTS / Linux 4.4.0-101-generic x86_64).

My feeling is that this is either a kernel issue or an ext4 mount / format option, however I am not sure. Any ideas?

This issue is likely related to #25.

Question

Excuse me, can anybody explain what the meaning of rename/24.t? Why does the directory have multiple nlinks? It seems my btrfs also cannot pass this case.

Hi!
I would be interested in handling the rewriting of the test suite for GSoC.
I saw the experimental start and would like to add some highlights for the questions raised in the PR, and in addition to the GSoC summary:

Is it worthwhile? There are a lot of tests to convert

In addition to make debugging easier, it could also lower the entry barrier for potential contributors/reviewers.
As mentioned in the summary, sh is harder to debug but also to review, with sometimes surprising behavior.
Also, if we rewrite the tests, duplications due to the lack of parameterization and inheritance would probably not make the number of tests to convert a big deal.

Are the C bindings worth the trouble for all functions? I initially
planned to call the function-under-test directly with C, like the
original pjdfstest. But Python's os module is very close to C. For
example, os.symlink is basically the same thing as symlink(2) except
that it accepts Python paths as arguments instead of C strings, and it
raises exceptions on error rather than setting errno.

It depends on the language that will be finally chosen, but for example, Python implements almost all POSIX syscalls with calling conventions very similar to those of C.
From what I have checked, the only missing that are present in pdjfstest.c are these ones:

• openat
• unlinkat
• mkdirat
• linkat
• symlinkat
• renameat
• mkfifoat
• mknodat
• bind
• bindat
• connectat
• fchmodat
• fchownat
• fchflags
• chflagsat
• fstatat
• lpathconf
• utimensat

(The bold functions have tests.)

Though, to be fair, most of those -at functions are replaced by the dir_fd parameter (except for bindat and connectat).
So, the only functions which would potentially need bindings are lpathconf, bindat and connectat.

This would also allow us to improve the documentation, which for the moment (no offense!) is rather scarce.

Language choice

Python

Pros

• Easier to review
• Syscalls availability (os module)
• Larger community

Cons

• Performance: Python is definitely not the best in terms of performance, but does it really matter for our case, since we mostly test IO?
• Setup

Rust

Pros

• Performance
• Binary: Tests could be compiled into one binary and distributed this way, instead of having to setup an environment
• Fearless concurrency
• Safety

Cons

• Rely on external dependency: not sure of how much this is a con, but to use syscalls, we cannot rely on the stdlib since it provides no guarantees (and wasn't built for this). But we can use for example nix or rustix.
• Community: Not really a big problem (I'm myself a huge Rust advocate!), but the community is rather small compared to the others

Go

Pros

• Syscalls availability (syscall module)
• Performance
• Binary: Same as for Rust

Cons

• Not so fearless concurrency
• Not so safe (debatable?)

ATF integration

I maybe misunderstood something, but I'm not sure of why is it needed to support ATF, given the fact that kyua supports TAP (and even plain) tests and that it seems to produce reports even for non-ATF tests.
A Kyuafile would probably be sufficient to output reports.

Recently I did some tests without noticing that I am actually testing XFS and the pjdfstest doesn't support XFS file system.
The outcome is that, there is one failed testcase, symlink-03, which creates a symbolic link of 4095 characters length.

not ok 1 - tried 'symlink .............', expected 0, got ENAMETOOLONG

For XFS filesystem, XFS_SYMLINK_MAXLEN is limited to 1024 characters according to this patch. Since XFS performs better than EXT4 in some scenarios and is becoming increasingly popular, wouldn't it be nice if some slight changes are made thus the pjdfstest could support XFS?

Many file systems update a file's ctime when it gets renamed. However, POSIX does not actually require that. POSIX just says "Some implementations mark for update the last file status change timestamp of renamed files and some do not". The rename/00.t test should be updated to allow either behavior. https://pubs.opengroup.org/onlinepubs/9699919799/functions/rename.html

Line 29 is the "outer" loop intending to loop through various rename source inodes:

Lines 35, 53, 72, and 91 are "inner" loops intending to loop through the various rename destination inodes to be "overwritten" (if possible) in various scenarios

The inner loops are modifying the loop variable of the outer loop. Frankly, I didn't know this was possible... but it just so happens that our work on enhancing the labeling / messaging output as a result of each create_file() or expect() call clearly showed this.

Simple fix... use "type1" for the outer loop and "type2" for the inner loops.

PATH_MAX seems to be hard-coded everywhere. Unfortunately, when using some file systems (Gluster, for example), the real paths are longer than PATH_MAX.
There is no way (that I found, as opposed to NAME_MAX) that one can query the FS for PATH_MAX - it is just assumed to be 4096 everywhere.

I suspect if we can change dirgen_max and perhaps other functions to be able to get a hard-coded, lower PATH_MAX, we'll be able to overcome this limitation, which currently fails many tests.

I am getting weird test results, seemingly randomly occurring, against my file system - only on Linux and only on Travis CI. They all originate in chown/00.t. The problem seems to be that the sum of performed tests does not match the number of expected tests - see attached file sample_ok.txt.

Example:

• Expected: 1323
• ok (without TODO): 1292
• ok (with TODO): 19
• not ok (without TODO): 0
• not ok (with TODO): 8

Sum of tests: 1319, just 4 less than expected.

The weird thing is: Sometimes the test works and the numbers add up, sometimes the test "fails" (I explicitly check for the numbers to add up). It's about a 50/50 chance, see this build for instance. Just repeat and it may be different. Unfortunately, I can not reproduce this on any of my local machines. I also can not see any actual error coming from my code. It's just like sometimes, four tests are being ignored.

If I run my test locally, the output for chown/00.t looks like this: sample_ok_local.txt. The diff between a failed Travis build and my local build looks like this:

1320c1320,1324
< ok 1319 
---
> ok 1319
> ok 1320
> ok 1321
> ok 1322
> ok 1323

My interpretation is that pjdfstest "occasionally" does not run four tests towards the end of chown/00.t. How can I narrow this down? What might be an obvious place to look? Or should I just ignore that the numbers sometimes do not add up ... ?

Attempting to compile on Mac OS X 10.10.5 fails with error:
cc -D__OS_Darwin__ -DHAS_LCHMOD -DHAS_CHFLAGS -DHAS_LCHFLAGS pjdfstest.c -o pjdfstest pjdfstest.c:810:10: warning: implicit declaration of function 'mkfifoat' is invalid in C99 [-Wimplicit-function-declaration] rval = mkfifoat(NUM(0), STR(1), (mode_t)NUM(2)); ^ pjdfstest.c:856:11: warning: implicit declaration of function 'mknodat' is invalid in C99 [-Wimplicit-function-declaration] rval = mknodat(NUM(0), STR(1), ntype | NUM(3), dev); ^ 2 warnings generated. Undefined symbols for architecture x86_64: "_mkfifoat", referenced from: _call_syscall in pjdfstest-079f33.o "_mknodat", referenced from: _call_syscall in pjdfstest-079f33.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [pjdfstest] Error 1

This is because HAS_MKNODAT and HAS_MKFIFOAT get defined even though Mac OS X does not support them. Attached patch resolves this by ensuring they are undefined.
pjdfstest.c.diff.txt

Some of the developers contributing to pjdfstest use FreeBSD as their primary platform, however there are end-users that use Linux and OS X. In order to catch issues sooner, rather than later, we should integrate the project into Travis-CI (https://travis-ci.org). Doing so will give us sanity checks with Linux, clang, gcc, and perl/Prove.

Part of the work (incomplete) is being done on https://github.com/yaneurabeya/pjdfstest/tree/travis-integration .

expect 0 -u 65534 -g 65534 symlink ${n2} ${n1}/${n3}
should be
expect 0 -u 65534 -g 65534 symlink ${n1}/${n2} ${n1}/${n3}

please check it also.

When running my filesystem against a code coverage analysis tool, I figured that the read routine was not triggered at all while testing with pjdfstest. Is this intentional or more of a bug at my end? While I do understand that pjdfstest is not an I/O stress test or similar, it feels wrong to not even look at the read operation.

I see tests 5 & 6 in utimensat/08.t fail on ext4 file systems on two different distributions / kernels:

• openSUSE Leap 42.3 / Linux 4.4.103-36-default x86_64
• Ubuntu 16.4.03 LTS / Linux 4.10.0-42-generic x86_64

The output looks as follows:

1..9
ok 1
ok 2
ok 3
ok 4
not ok 5 - tried 'lstat pjdfstest_560bb3645b88906d133bc8f96929b619 atime_ns', expected 100000000, got 0
not ok 6 - tried 'lstat pjdfstest_560bb3645b88906d133bc8f96929b619 mtime_ns', expected 200000000, got 0
ok 7
ok 8
ok 9

The strange thing is, the tests do NOT fail when running on Travis CI (sudo-enabled virtual machine, Ubuntu 14.04 LTS / Linux 4.4.0-101-generic x86_64).

My feeling is that this is either a kernel issue or an ext4 mount / format option, however I am not sure. Any ideas?

This issue is likely related to #24.

Some of the tests assume that noexec are not set at the filesystem level at mount time. This unfortunately results in test failures on certain testcases.

Procedure:

mdmfs -s 120m md42 /mnt
mount -u -o noexec /mnt
cd /mnt
prove -rv /path/to/pjdfstest

Expected Result:

The testcases requiring exec should be at the bare minimum filtered out from the list of testcases to run.

Actual Result:

Some tests fail...

/mnt2/gcooper/git/pjdfstest/tests/ftruncate/11.t .. ^M
1..2^[[0m^M
/mnt2/gcooper/git/pjdfstest/tests/ftruncate/11.t: ./pjdfstest_2d3402b8511a1270cd462817ea887846: Permission denied^M
^[[31mnot ok 1 - tried 'truncate pjdfstest_2d3402b8511a1270cd462817ea887846 123', expected ETXTBSY, got 0^[[0m^M
ok 2^[[0m^M

/mnt2/gcooper/git/pjdfstest/tests/open/20.t ....... ^M
1..4^[[0m^M
/mnt2/gcooper/git/pjdfstest/tests/open/20.t: ./pjdfstest_698496727bf123be2e0b9084e62a42e8: Permission denied^M
^[[31mnot ok 1 - tried 'open pjdfstest_698496727bf123be2e0b9084e62a42e8 O_WRONLY', expected ETXTBSY, got 0^[[0m^M
^[[31mnot ok 2 - tried 'open pjdfstest_698496727bf123be2e0b9084e62a42e8 O_RDWR', expected ETXTBSY, got 0^[[0m^M
^[[31mnot ok 3 - tried 'open pjdfstest_698496727bf123be2e0b9084e62a42e8 O_RDONLY,O_TRUNC', expected ETXTBSY, got 0^[[0m^M
ok 4^[[0m^M

/mnt2/gcooper/git/pjdfstest/tests/truncate/11.t ... ^M
1..2^[[0m^M
/mnt2/gcooper/git/pjdfstest/tests/truncate/11.t: ./pjdfstest_4e2ab048c5ab4ef561ee9d381c04f68f: Permission denied^M
^[[31mnot ok 1 - tried 'truncate pjdfstest_4e2ab048c5ab4ef561ee9d381c04f68f 123', expected ETXTBSY, got 0^[[0m^M
ok 2^[[0m^M
^[[31mFailed 1/2 subtests ^[[0m^M

This will allow us to move away from the ad hoc/incorrect HAS_ macros. We might want to take a look at making the supported macro in misc.sh more intelligent while doing this.

expect 0 mkdir ${n2}/${n0} 0700                                                  
expect "0|EACCES" -u 65534 -g 65534 rename ${n2}/${n0} ${n2}/${n1}               
expect "0|EACCES" -u 65534 -g 65534 rename ${n2}/${n1} ${n2}/${n0}               

rename/21.t renames ${n2}/${n0} to ${n2}/${n1} while it doesn't have write permission to ${n2}/${n0}. The result can be 0 or EACCES. However, if the filesystem returns EACCES, it will return ENOENT to the next test because ${n2}/${n1} doesn't exist. The test needs to remove and recreate the directory or allow ENOENT in the next test.

Not a really issue but question and maybe improvement suggestion

Right now standard test output looks like that:

$ sudo prove -r -o ~/qa/pjdfstest/
/home/vastdata/qa/pjdfstest/tests/rmdir/07.t ............ Failed 2/10 subtests
/home/vastdata/qa/pjdfstest/tests/rmdir/08.t ............ Failed 1/10 subtests
/home/vastdata/qa/pjdfstest/tests/rmdir/09.t ............ ok
...
/home/vastdata/qa/pjdfstest/tests/rmdir/07.t   (Wstat: 0 Tests: 10 Failed: 2)
  Failed tests:  2-3

Does it mean I need to find 2nd and 3rd expect and those should be exactly the needed subtests?
Does any subtest starting with expect?

Thanks

"expect 0 -u 65534 -g 65534 symlink ${n2} ${n1}/${n3}"
should be
"expect 0 -u 65534 -g 65534 symlink ${n1}/${n2} ${n1}/${n3}"

right?

pjdfstest covers a ton of control-path functionality, but there's some stuff that it doesn't touch. This is a metabug to track its gaps.

• file handle access with fhopen(2) etc. Used by userspace NFS servers.
• POSIX.1e ACLs
• NFSv4 ACLs
• Advisory locking with flock(2) or fcntl(2)
• Extended attributes (#52)
• Any kind of datapath access (lseek, read, write, mmap, copy_file_range, and hole-punching)
• Tricky readdir corner cases. telldir/seekdir, etc.

It would be great if pjdfstest had tests for extended attributes. The user APIs are pretty OS-specific, though, so the tests would probably need to be os-specific too.

FreeBSD has returned EMLINK for some time now, so unfortunately the open16.t tests fail on FreeBSD. I had to parameterize out the error to check for EMLINK in lieu of ELOOP.

So some parts of the test are failing so I am trying to run the steps manually to see what exactly is being run that is not passing. I am starting with the most simple thing I could find:

expect 0 create ${nx} 0644

couldn't read file "0": no such file or directory

What is the 0 supposed to reference? I understand that ${nx} is supposed to be the file that gets created but just cant figure out what 0 is.

Also how can I figure out what code was executed from the fail messages that get returned after a run? So for example this was one of my runs below:

Running open/06.t

/qa_tools/pjdfstest-master/tests/open/06.t (Wstat: 0 Tests: 144 Failed: 20)
Failed tests: 9-11, 13-15, 21, 25, 34, 38, 70-71, 73-74
80, 84, 116, 118, 122, 124

what do the number ranges correspond to? like what was executed for 9-11 to fail or where would i look for that?

Any help would be appreciated!

Alibaba Cloud NAS failed in pjdfstest/tests/open/07.t as following

/root/pjdfstest/tests/open/07.t ............. 
not ok 5 - tried '-u 65534 -g 65534 open pjdfstest_f24a42815d59c16a4bde54e6559d0390 O_RDONLY,O_TRUNC', expected EACCES, got 0
not ok 7 - tried '-u 65533 -g 65534 open pjdfstest_f24a42815d59c16a4bde54e6559d0390 O_RDONLY,O_TRUNC', expected EACCES, got 0
not ok 9 - tried '-u 65533 -g 65533 open pjdfstest_f24a42815d59c16a4bde54e6559d0390 O_RDONLY,O_TRUNC', expected EACCES, got 0
Failed 3/23 subtests

However the The Single UNIX ® Specification, Version 2 suggests the result of such case is undefined.

O_TRUNC
If the file exists and is a regular file, and the file is successfully opened O_RDWR or O_WRONLY, its length is truncated to 0 and the mode and owner are unchanged. It will have no effect on FIFO special files or terminal device files. Its effect on other file types is implementation-dependent. The result of using O_TRUNC with O_RDONLY is undefined.

When I try to check the actual effect on the file, it turns out the file system DOES return EACCES if the file size is non-zero. See the constructed test case trunc.t for details.

In fact, when file size is 0, O_TRUNC will have no effect at all. It is reasonable to treat it as an undefined behavior. It might be more meaningful to test against a non-empty file instead of an empty one and check the size after the operation.

What do you think? @pjd

Would a patch to add a .soec file for RPM package building be accepted?

When I use pjdfstest to test again a FUSE filesystem, the test suite open/06.t will hang for FIFO files, for example:

expect EACCES -u 65534 -g 65534 open ${n1} O_WRONLY

It expect EACCESS but if FUSE filesystem does not perform the permission checking correctly (may a bug in FUSE module), this test will just hang (wait for another one to open it as read).

It's better to add O_NONBLOCK there, as other test cases.

As noted on #10, there are several pjdfstest failures on OS X that need to be resolved in order for the OS X test run to be green.

Here's a summary of the failures:

-------------------
tests/chown/00.t          (Wstat: 0 Tests: 1323 Failed: 38)
  Failed tests:  1098, 1102, 1108, 1113, 1117, 1123, 1128
                1132, 1138, 1143, 1147, 1153, 1158, 1162
                1168, 1173, 1177, 1183, 1188, 1195, 1201
                1209, 1216, 1222, 1230, 1237, 1243, 1251
                1258, 1264, 1272, 1279, 1285, 1293, 1300
                1306, 1314, 1321
tests/chown/07.t          (Wstat: 0 Tests: 132 Failed: 19)
  Failed tests:  7, 12, 20, 27, 32, 40, 47, 52, 60, 67, 72
                80, 87, 92, 100, 107, 112, 120, 127
tests/ftruncate/12.t      (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  2
tests/link/00.t           (Wstat: 0 Tests: 202 Failed: 46)
  Failed tests:  56-67, 70-72, 74, 76, 82-93, 96-98, 100
                102, 147-150, 152, 154-157, 159, 183, 190
tests/mkfifo/03.t         (Wstat: 256 Tests: 4 Failed: 1)
  Failed test:  3
  Non-zero exit status: 1
tests/mknod/03.t          (Wstat: 256 Tests: 12 Failed: 7)
  Failed tests:  3, 5-7, 9-11
  Non-zero exit status: 1
tests/rename/00.t         (Wstat: 0 Tests: 150 Failed: 19)
  Failed tests:  38-40, 42, 44-45, 53-55, 57, 59-60, 96
                100, 104, 108, 112, 116, 120
tests/rename/09.t         (Wstat: 0 Tests: 2353 Failed: 16)
  Failed tests:  2269-2272, 2279-2281, 2284, 2289-2292, 2299-2301
                2304
tests/rename/10.t         (Wstat: 0 Tests: 2099 Failed: 8)
  Failed tests:  2056-2058, 2061, 2063-2065, 2068
tests/rename/21.t         (Wstat: 0 Tests: 16 Failed: 1)
  Failed test:  5
tests/symlink/03.t        (Wstat: 256 Tests: 6 Failed: 1)
  Failed test:  4
  Non-zero exit status: 1
tests/truncate/12.t       (Wstat: 0 Tests: 3 Failed: 1)
  Failed test:  2
tests/unlink/00.t         (Wstat: 0 Tests: 112 Failed: 6)
  Failed tests:  37-39, 42-44
Files=232, Tests=8677, 236 wallclock secs ( 3.44 usr  0.97 sys + 47.71 cusr 47.52 csys = 99.64 CPU)
Result: FAIL

Script done, output file is ts

I'll attach the typescript snippets later, with appropriate review/analysis.

I would like to run these tests, but don't have root privileges. What would need to change to run these tests as a non-root user?

When I configured pjdfstest on my filesystem, I got warnings:

checking sys/sysmacros.h usability... no
checking sys/sysmacros.h presence... yes
configure: WARNING: sys/sysmacros.h: present but cannot be compiled
configure: WARNING: sys/sysmacros.h:     check for missing prerequisite headers?
configure: WARNING: sys/sysmacros.h: see the Autoconf documentation
configure: WARNING: sys/sysmacros.h:     section "Present But Cannot Be Compiled"
configure: WARNING: sys/sysmacros.h: proceeding with the compiler's result
checking for sys/sysmacros.h... no
checking for bindat... no

Then I got compiling error when executed make pjdfstest:

cc -DHAVE_CONFIG_H -I.    -Wall -Werror -g -O2 -MT pjdfstest.o -MD -MP -MF .deps/pjdfstest.Tpo -c -o pjdfstest.o pjdfstest.c
pjdfstest.c: In function ‘show_stat’:
pjdfstest.c:590:2: error: expected expression before ‘else’
  590 |  else if (strcmp(what, "major") == 0)
      |  ^~~~
pjdfstest.c:593:30: error: implicit declaration of function ‘minor’ [-Werror=implicit-function-declaration]
  593 |   printf("%u", (unsigned int)minor(sp->st_rdev));
      |                              ^~~~~
pjdfstest.c: In function ‘call_syscall’:
pjdfstest.c:873:9: error: implicit declaration of function ‘makedev’ [-Werror=implicit-function-declaration]
  873 |   dev = makedev(NUM(fa + 3), NUM(fa + 4));
      |         ^~~~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:401: pjdfstest.o] Error 1

It seems the macros are defined in my /usr/include/x86_64-linux-gnu/sys/sysmacros.h:

/* Definitions of macros to access `dev_t' values.
   Copyright (C) 1996-2020 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

   The GNU C Library is free software; you can redistribute it and/or
   modify it under the terms of the GNU Lesser General Public
   License as published by the Free Software Foundation; either
   version 2.1 of the License, or (at your option) any later version.

   The GNU C Library is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
   Lesser General Public License for more details.

   You should have received a copy of the GNU Lesser General Public
   License along with the GNU C Library; if not, see
   <https://www.gnu.org/licenses/>.  */

#ifndef _SYS_SYSMACROS_H
#define _SYS_SYSMACROS_H 1

#include <features.h>
#include <bits/types.h>
#include <bits/sysmacros.h>

#define __SYSMACROS_DECL_TEMPL(rtype, name, proto)                           \
  extern rtype gnu_dev_##name proto __THROW __attribute_const__;

#define __SYSMACROS_IMPL_TEMPL(rtype, name, proto)                           \
  __extension__ __extern_inline __attribute_const__ rtype                    \
  __NTH (gnu_dev_##name proto)

__BEGIN_DECLS

__SYSMACROS_DECLARE_MAJOR (__SYSMACROS_DECL_TEMPL)
__SYSMACROS_DECLARE_MINOR (__SYSMACROS_DECL_TEMPL)
__SYSMACROS_DECLARE_MAKEDEV (__SYSMACROS_DECL_TEMPL)

#ifdef __USE_EXTERN_INLINES

__SYSMACROS_DEFINE_MAJOR (__SYSMACROS_IMPL_TEMPL)
__SYSMACROS_DEFINE_MINOR (__SYSMACROS_IMPL_TEMPL)
__SYSMACROS_DEFINE_MAKEDEV (__SYSMACROS_IMPL_TEMPL)

#endif

__END_DECLS

#ifndef __SYSMACROS_NEED_IMPLEMENTATION
# undef __SYSMACROS_DECL_TEMPL
# undef __SYSMACROS_IMPL_TEMPL
# undef __SYSMACROS_DECLARE_MAJOR
# undef __SYSMACROS_DECLARE_MINOR
# undef __SYSMACROS_DECLARE_MAKEDEV
# undef __SYSMACROS_DEFINE_MAJOR
# undef __SYSMACROS_DEFINE_MINOR
# undef __SYSMACROS_DEFINE_MAKEDEV
#endif

#define major(dev) gnu_dev_major (dev)
#define minor(dev) gnu_dev_minor (dev)
#define makedev(maj, min) gnu_dev_makedev (maj, min)

#endif /* sys/sysmacros.h */

I'm using ubuntu 20.04 and not very familiar with the autoconf, could anyone give me some advice please to fix this case?