richard_fanta <richard.fanta@morganstanley.com>:

--- In Boost-Users@yahoogroups.com, "Ben Hutchings" <ben.hutchings@b...> wrote:

...

richard_fanta <richard.fanta@m...> wrote:

...

Beman Dawes <bdawes@a...> wrote:

...

...

Looking at the filesystem library and the attributes work in boost-sandbox, I don't immediately see "last access time" being available for a file or directory.

"Last access time" was included in Dietmar Kuehl's original dir_it.

Can someone kindly tell me why this was removed? It's highly useful, and part of every filesystem that I've seen. <snip> Perhaps we should do more to support attribute query within the

At 01:02 AM 5/6/2003, richard_fanta wrote: main library, but I don't really think we should include any that aren't reliably supported by at least POSIX, Windows, and ISO-9660 systems.

Your point is well made. However, it does seem odd that a feature that is useful for >95% of all typical usage shouldn't be in the library.

What does that figure refer to, if anything?

Typical application usage. Yes, mileage can vary.

Out of the last 50 apps you wrote that did file access, how many involved CD-ROMS/DVDs that were ISO 9660 filesystems?

I think most of them could quite happily have worked with files on CD-ROMs, but then I tend to write general-purpose code rather than very specific applications. A few of them needed to know file modification times. <snip>

...

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.

...

Note that Windows NT maintains access times at quite a low resolution, to reduce this cost.

Low resolution or not, it's there. When the file changes, the timestamp is updated. That's information that many applications would find useful. <snip>

What you're talking about is the modification time, not the access time. I agree that *that* is useful and widely supported, but it's not what you were originally asking for!