The wording for ftruncate() requires mtime and ctime updates on successful
completion, even when no change in file size occurs. However, truncate()
does not describe what happens when no size change occurs, which is
inconsistent with ftruncate(), and which is at odds with XBD 4.8 stating
that ctime updates occur even if the metadata written (in this case, the
file size) is identical to what it already was.

Desired Action

At line 67570 [XSH truncate() DESCRIPTION], change the sentence:

"Upon successful completion, if the file size is changed, truncate( )
shall mark for update the last data modification and last file status
change timestamps of the file, and the S_ISUID and S_ISGID bits of the
file mode may be cleared."

to:

"Upon successful completion, truncate( ) shall mark for update the last
data modification and last file status change timestamps of the file,
and the S_ISUID and S_ISGID bits of the file mode may be cleared."

Unclear explanation about when last file status change timestamp shall be updated

Relationships

Notes

(0001127)
mkerrisk (reporter)2012-02-14 10:36

While I agree with Eric about the strange inconsistency between truncate() and ftruncate(), the approved change *will* make Linux nonconformant.

On Linux, the ftruncate() system call always changes the file timestamps, even if the file size is not changed. However, Linux truncate() only changes the timestamps if the file size changes. (This observation is based on my reading of the kernel source and some userspace programs to test these details.) I haven't delved into the history, but quite possibly the Linux behavior occurs because the implementers looked closely at the specifications for these two functions.

I think some consideration should be given to existing Linux behavior before modifying the standard in a way that renders Linux nonconformant.