Austin Group Minutes of the 29 Mar 2007 Teleconference Austin-358 Page 1 of 1 Submitted by Andrew Josey, The Open Group. March 30, 2007 Attendees Andrew Josey, The Open Group Geoff Clare, The Open group Nick Stoughton, USENIX, ISO/IEC OR Ulrich Drepper, Red Hat Don Cragun , Sun, PASC OR Mark Brown, IBM, TOG OR Action item review --------------------- ACTION AI-2005-01-01: Don Cragun to present paper on pathname resolution. OPEN ACTION AI-2006-09-02: Ulrich and Nick to develop a draft PAR and criteria for C++ POSIX binding for discussion, and to produce the Study Group final report by March 31. CLOSED The PASC SEC is currently voting on a motion to extend the life of the study group for another six months. Indications are that the motion will pass. ACTION 2007-02-01: Andrew Josey to make a pass through current closed aardvarks against approved std, to move items to SD-5 or interpretations when ready. CLOSED: Andrew has prepared updates for SD5, and also the list of interpretations and circulated those to the reflector. These are also now documented in Austin/357. ACTION 2007-02-02: Andrew Josey to talk to IEEE and ITTF about the name to use in the text: is POSIX.1:200x satisfactory to all? CLOSED No status yet to report from IEEE, we plan to make the name change in D3R as its a macro. ACTION 2007-02-06: Ulrich to research issue 15 and propose text for XSH intro to explain directory searching, with special respect to the *at() functions. OPEN (Geoff has posted some mail on this, come back to this when Ulrich has the cycles) ACTION 2007-02-08: Mark Brown to produce sample pages with various ways of presenting c99 information, including synopsis changes, Geoff Clare's proposal, and no change, and to circulate these pages. OPEN ACTION 2007-02-09: ALL review sample c99 pages when available with an audience that includes non standards developers. OPEN (dependent on previous action) Aardvark Bug Reports -------------------- We expect to discuss the finegrain aardvark reports next week http://www.opengroup.org/austin/aardvark/finegrain/ We discussed how we should handle the issues raised on the reflector, primarily pathconf and fine granularity time stamps. It was decided to start with the aardvark and then return to the issue later. All changes in the aardvark are against D2R. xbdfgbug.txt XBDfg ERN 1 Accept as marked below We reviewed the comments in mail eq 10329 We agreed to insert the name of the structure "the file characteristrics structure, struct stat, as described in " We felt that we did not need to add further rationale as the text does has not changed due to the addition of fine granularity timestamps. Revised text becomes: File Times Update Each file has three distinct associated timestamps: the time of last data access, the time of last data modification, and the time the file status last changed. These values are returned in the file characteristics structure, struct stat, as described in . Each function or utility in IEEE Std 1003.1-200x that reads or writes data or changes file status indicates which of the appropriate timestamps shall be "marked for update". If an implementation of such a function or utility marks for update one of these timestamps in a place or time not specified by IEEE Std 1003.1-200x, this shall be documented, except that any changes caused by pathname resolution need not be documented. For the other functions or utilities in IEEE Std 1003.1-200x (those that are not explicitly required to read or write file data or change file status, but that in some implementations happen to do so), the effect is unspecified. An implementation may update timestamps that are marked for update immediately, or it may update such timestamps periodically. At the point in time when an update occurs, any marked timestamps shall be set to the current time and the update marks shall be cleared. All timestamps that are marked for update shall be updated when the file ceases to be open by any process or before a stat(), fstat(), lstat(), fsync(), utime(), utimensat(), or utimes() is successfully performed on the file. Other times at which updates are done are unspecified. Marks for update, and updates themselves, shall not be done for files on read-only file systems; see Section 3.304 (on page 73). The resolution of timestamps of files in a file system is implementation-defined, but shall be no coarser than one-second resolution. The three timestamps shall always have values that are supported by the file system. Whenever any of a file's timestamps are to be set to a value V according to the rules of the preceding paragraphs of this section, the implementation shall immediately set the timestamp to the greatest value supported by the file system that is not greater than V. XBDfg ERN 2 Accept XBDfg ERN 3 Accept XBDfg ERN 4 Accept as marked below Add a new paragraph after line 12752: For compatibility with previous editions of this standard the st_atime macro shall be defined with the value st_atim.tv_sec. Similarly, st_ctime and st_mtime shall be defined as macros with the values st_ctim.tv_sec and st_mtim.tv_sec, respectively. XBDfg ERN 5 Accept as marked below Add a new paragraph to rationale for : Upon assignment, file timestamps are immediately converted to the resolution of the file system by truncation (i.e., the recorded time can be older than the actual time). For example, if the file system resolution is 1 microsecond, then a conforming stat() must always return an st_mtim.tv_nsec that is a multiple of 1000. Some older implementations returned higher-resolution time stamps while the inode information was cached, and then spontaneously truncated the tv_nsec fields when they were stored to and retrieved from disk, but this behavior does not conform. XBDfg ERN 6 duplicate of 5 XBDfg ERN 7 Accept XBDfg ERN 8 Accept XBDfg ERN 9 Accept XBDfg ERN 9 OPEN Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. Next teleconference meeting will be 5 April 2007. Note that the time will be at 16:00 UK local time New number for next week: +1 877-421-0003 Passcode: 953276 See http://www.opengroup.org/austin/. An IRC channel will be available for the meeting irc://irc.freestandards.org #austin irc://irc.freestandards.org/austin ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic