Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000485 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2011-08-10 16:18 2019-06-10 08:55
Reporter mdempsky View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Matthew Dempsky
Organization OpenBSD
User Reference
Section futimens, utimensat
Page Number 969
Line Number 32407-32408
Interp Status Approved
Final Accepted Text see Note: 0000949
Summary 0000485: Unclear explanation about when last file status change timestamp shall be updated
Description The description for futimens() and utimensat() states "Upon completion, futimens() and utimensat() shall mark the last file status change timestamp for update." I have two questions about this wording:

1. It says "Upon completion", not "Upon *successful* completion" as in the "Return Value" section. Shall the last file status change timestamp thus be marked for update even if (e.g.) the times argument points to invalid timespec values? (I assume no, as in some unsuccessful completion scenarios doing so is impossible, but strict reading suggests yes.)

2. Shall the file status change timestamp still be marked for update if both times elements are set to UTIME_OMIT? (Strictly reading again suggests yes, which makes sense to me, but I wanted to confirm as at least Linux 2.6.32 does not implement that behavior.)
Desired Action Change the wording in the Description section for utimensat() and futimens() 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."
Tags tc2-2008
Attached Files

- Relationships
related to 0000489Closedajosey truncate should affect timestamps even for no size change 

-  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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker