Re: Why isn't the "last access time" part of the filesystem library?

--- In Boost-Users@yahoogroups.com, "Ben Hutchings" wrote:

...

Beman Dawes wrote:

...

At 01:02 AM 5/6/2003, richard_fanta 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

richard_fanta wrote: dir_it.

...

...

...

Can someone kindly tell me why this was removed? It's highly

useful,

...

and part of every filesystem that I've seen.

ISO/IEC 9660:1999 filesystems don't supply a "last access" time stamp, perhaps because the original uses were on write-once media.

Which filesystems adhere to this spec other than CD-ROMs?

Many DVDs use this too, but for most purposes they're basically just higher-capacity CDs.

...

...

Perhaps we should do more to support attribute query within the

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?

...

Other options: -For ISO 9660 filesystems, use the time created as the "last access" time stamp. -Throw a "FeatureNotSupportedException" or somesuch.

Then the feature won't be at all portable, and might as well not be supported at all.

I'm sure there are better solutions; also, though these suggestions might be unpleasant () for some applications, but I don't see how they prohibit portability.

Access times are far from a universal OS feature,

On which specific (and hopefully widespread) examples do you base this?

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. As well as the Windows filesystems, "Last access" is also there in every Linux/Unix filesystem (incl. Mac) that I've seen and others (e.g. VMS and some IBM filesystems if memory serves me). I can clearly see the justification for doing something reasonable for ISO 9660 filesystems, but I don't see why this has to preclude including a feature that is widely useful. In most environments I've seen, the 80/20 or 90/10 rule is applied. Namely, you design for features that 80-90% of usage is likely to be encountered and accomodate the rest in some reasonable manner. Why not here?