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

From: Ben Hutchings (ben.hutchings_at_[hidden])
Date: 2003-05-09 10:21:26

Beman Dawes wrote:
> At 06:13 AM 5/8/2003, Peter Dimov wrote:
<snip> 
>  >This is a misunderstanding. Last access time (struct 
>  >stat::st_atime) and creation time (st_ctime) aren't universal.

Unix's ctime is actually change time, not creation time - it is the
time when certain metadata were last changed.

>  >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.

You're mixing the concepts of filesystem API and the filesystem on
disk.  Normally the same filesystem API can be used for any file-
system supported by the OS, and file times on an inherently read-
only filesystem can appear as modification time and (if the OS
supports the notion) as creation or change time.

> 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.

Seems reasonable to me.

> 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"?

Use std::time_t(-1) to be consistent with std::time and
std::mktime.