Should the behavior of "O_RDONLY|O_TRUNC" be undefined?

[yujunz]

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

[pjd]

On 12/23/19 04:08, Yujun Zhang wrote: Alibaba Cloud NAS failed in pjdfstest/tests/open/07.t <https://github.com/pjd/pjdfstest/blob/master/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 <https://pubs.opengroup.org/onlinepubs/007908799/xsh/open.html> 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 DOSE return |EACCES| /if the file size was non-zero/. See the constructed test case trunc.t <https://github.com/juicedata/pjdfstest/blob/1fd5d7f9a859146713de1207490a3e3032e18c86/tests/open/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 <https://github.com/pjd>

All sounds reasonable and indeed testing with non-empty file makes more sense, because at the very least we want to make sure the file is not truncated.

…

-- Pawel Jakub Dawidek