Re: [Boost-Users] Re: Why isn't the "last access time" part of the filesystem library?

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-05-08 09:30:49

At 06:13 AM 5/8/2003, Peter Dimov wrote:

 >richard_fanta wrote:
 >> --- In Boost-Users_at_[hidden], "Ben Hutchings"
 >> <ben.hutchings_at_b...> wrote:
 >>
 >>> Access times are far from a universal OS feature,
 >>
 >> On which specific (and hopefully widespread) examples do you base
 >> this?
 >
 >FAT?
 >
 >>> and updates to them may be disabled because the volume is read-only
 >>> (whether or not the underlying medium is read-only) or purely to
 >>> avoid the cost of updating them.
 >>
 >> Even if the volume is read-only from one machine, it might still help
 >> to know when the file was last altered.
 >
 >This is a misunderstanding. Last access time (struct stat::st_atime) and
 >creation time (st_ctime) aren't universal. Modification time (st_mtime) 
is
 >common, except on read-only filesystems, which typically only have ctime.
 >Judging by your "last altered" remark, you mean mtime but call it "last
 >access."
 >
 >I think that it would be entirely reasonable (and very useful - can avoid
 >reading a file if it hasn't changed since last read) to provide mtime. On
 >read-only filesystems, the creation time should be returned.

Yes, I had a similar thought.

What format should be used to report the mtime? I'd prefer to keep the 
coupling to other Boost libraries low, so I guess that would mean just 
using std::time_t. That also has the advantage of not promising higher 
resolution than can actually be delivered by most platforms.

What to do if the filesystem doesn't attach any time at all to a file? Fail 
at compile time? Always return some date in the past, like January 1, 1900, 
that is impossible as a real mdate (since computers were not invented yet) 
and so can be relied upon to indicate "no date available"?

--Beman