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

Notes
(0000939) eblake (manager) 2011-08-11 17:44	This was discussed on the 11 Aug 2011 call, but while it was agreed that there is a problem, the resolution is not clear without some more research. We agree that most places in the standard only talk about timestamp modifications on successful completion; returning an error generally means that no timestamp update should be permitted. The desired action is correct on that front, but it only addresses point 1 of the problem, without any mention of how to solve point 2. Ultimately, the problem is deciding what constitutes successful completion. For example, write() documents that if nbytes is 0, an implementation may either blindly return success or do error checking, but that no mtime or ctime updates occur. Conversely, if nbytes is non-zero, a successful completion of write() must mark mtime and ctime for update, even if the data that was written matches what was already present in the file before the write(). On the one hand, this timestamp update can be useful for auditing purposes (ctime represents the last time someone with access to the file tried to modify it, even if they didn't make any other modifications); on the other hand, forcing implementations to update ctime when nothing else changes is always slower than allowing implementations to skip a ctime update. Do implementations update ctime even when chown makes no ownership changes? Do they behave differently regarding ctime updates if both owner and group are -1, compared to the case where at least one of owner or group was non-negative, even if the end result was no change in ownership information? Do implementations update ctime even when chmod makes no changes in the mode? And with futimens, we have a range of choices to consider: require that success always update ctime even if neither atime nor mtime changed from prior value, permit ctime to remain unchanged if no other change was made, require that ctime be unchanged if no other change was made, special case just double UTIME_OMIT as no ctime change while requiring ctime changes in other cases even when no atime or mtime change occurs, and so forth. We already special case double UTIME_OMIT elsewhere (the paragraph at 32393 requires that double UTIME_OMIT skips ownership checks done by all other uses), so since we already have short-circuiting there, it seems like we should follow the lead of write() in documenting two different ctime behaviors. That is, it would be nice if ctime updates are mandatory on success even when atime and mtime are unchanged if at least one time was not UTIME_OMIT, while ctime updates must not happen if both times are UTIME_OMIT. But before we can go this route, we need to survey existing implementation practice, to see if this would conflict with design choices already made. It may also be that this research point to a need to relax chown and chmod to allow optimizations of not requiring ctime updates when no other metadata changes.

(0000947) geoffclare (manager) 2011-08-31 14:53	In response to Note: 0000939, I believe that as a general principle if a call is made that sets some file metadata to a specific value, then the ctime should be updated regardless of whether the specified value happens to be the same as the one the file already had. Therefore the only relaxation that we should consider is for the specific case of chown() with both owner and group arguments equal to -1, and futimens()/utimensat() with UTIME_OMIT in both times.

(0000949) eblake (manager) 2011-09-01 15:20 edited on: 2011-09-01 15:25	Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- The standard requires that timestamps be marked for update even when values being written are identical to what is already present. However, it is unclear whether utimensat is required to write anything when both arguments use UTIME_OMIT, and the wording for chown when both arguments are -1 was difficult to follow. The intent is that implementations may, but not must, optimize these two cases. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- Make the following changes: Change the wording in the Description section for utimensat() and futimens() [line 32407] from: "Upon completion, futimens() and utimensat() shall mark the last file status change timestamp for update." to: "Upon successful completion, futimens() and utimensat() shall mark the last file status change timestamp for update, with the exception that if both tv_nsec fields are set to UTIME_OMIT, the file status change timestamp need not be marked for update." Change the wording in the Description section for chown() and fchownat() [line 22337] from: "If owner or group is specified as (uid_t)−1 or (gid_t)−1, respectively, the corresponding ID of the file shall not be changed. If both owner and group are −1, the times need not be updated. Upon successful completion, chown( ) shall mark for update the last file status change timestamp of the file." to: "If owner or group is specified as (uid_t)−1 or (gid_t)−1, respectively, the corresponding ID of the file shall not be changed. Upon successful completion, chown( ) shall mark for update the last file status change timestamp of the file, except that if owner is (uid_t)-1 and group is (gid_t)−1, the file status change timestamp need not be marked for update."

(0001300) ajosey (manager) 2012-06-29 16:19	Interpretation proposed 29 June 2012 for final 45 day review

(0001341) ajosey (manager) 2012-08-30 09:11	Interpretation approved 30 Aug 2012

Issue History
Date Modified	Username	Field	Change
2011-08-10 16:18	mdempsky	New Issue
2011-08-10 16:18	mdempsky	Status	New => Under Review
2011-08-10 16:18	mdempsky	Assigned To	=> ajosey
2011-08-10 16:18	mdempsky	Name	=> Matthew Dempsky
2011-08-10 16:18	mdempsky	Organization	=> OpenBSD
2011-08-10 16:18	mdempsky	Section	=> futimens, utimensat
2011-08-10 16:18	mdempsky	Page Number	=> http://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html [^]
2011-08-10 16:18	mdempsky	Line Number	=> Paragraph 5 under Description
2011-08-10 17:11	Don Cragun	Page Number	http://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html [^] => 969
2011-08-10 17:11	Don Cragun	Line Number	Paragraph 5 under Description => 32407-32408
2011-08-10 17:11	Don Cragun	Interp Status	=> ---
2011-08-11 17:44	eblake	Note Added: 0000939
2011-08-31 14:53	geoffclare	Note Added: 0000947
2011-09-01 15:20	eblake	Note Added: 0000949
2011-09-01 15:22	eblake	Note Edited: 0000949
2011-09-01 15:25	eblake	Note Edited: 0000949
2011-09-01 15:27	eblake	Interp Status	--- => Pending
2011-09-01 15:27	eblake	Final Accepted Text	=> see Note: 0000949
2011-09-01 15:27	eblake	Status	Under Review => Interpretation Required
2011-09-01 15:27	eblake	Resolution	Open => Accepted As Marked
2011-09-01 15:27	eblake	Tag Attached: tc2-2008
2011-09-01 15:50	eblake	Relationship added	related to 0000489
2012-06-29 16:19	ajosey	Interp Status	Pending => Proposed
2012-06-29 16:19	ajosey	Note Added: 0001300
2012-08-30 09:11	ajosey	Interp Status	Proposed => Approved
2012-08-30 09:11	ajosey	Note Added: 0001341
2019-06-10 08:55	agadmin	Status	Interpretation Required => Closed

Aardvark Mark IV