Interpretations

Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretation for IEEE Std 1003.1™-1990 IEEE Standard for Information Technology--Portable Operating System Interfaces (POSIX®)

Copyright © 2001 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

Interpretation Request #52
Topic:
timestamps on read-only filesystems Relevant Sections: 2.2.2.69, 2.3.5 Classification: No Change

POSIX.1-1990 Section 2.2.2.69 defines "read only file system": A file system that has implementation defined characteristics restricting modifications. POSIX.1-1990 Section 2.3.5 "file times update" states: Updates are not done for files on read-only file systems. Is it permissible for an implementation to update the st_atime attribute held in-core but yet prevent the update of that attribute for the file on the read-only filesystem?

Interpretation Response
No, such an implementation is not conforming.

Rationale for Interpretation
The statement that a read-only filesystem has implementation-defined restrictions on modification does not prevent the standard itself from specifying restrictions. Subclause 2.3.5 states that st_atime shall not be updated for a file on a read-only file system. Subclause 2.2.2.69 says that there are implementation-defined restrictions restricting modification, but these are in addition to any restrictions imposed by the standard. Note that read() marks the file for update, even on a read-only filesystem, but the update is never done. This distinction is not particularly relevant to an application, since there is no way to find out that a time is "marked" but not "updated."

Editorial note (not part of the interpretation)
It would improve readability if these two subclauses referenced each other, but the fact that they don't doesn't change what is required.