RE: [Boost-Users] Re: Why isn't the "last access time" part of the filesystem library?
Beman Dawes <bdawes@a...> 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 <richard.fanta@morganstanley.com> 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?
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. Access times are far from a universal OS feature, 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. Note that Windows NT maintains access times at quite a low resolution, to reduce this cost.
--- In Boost-Users@yahoogroups.com, "Ben Hutchings" <ben.hutchings@b...> wrote:
Beman Dawes <bdawes@a...> 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 <richard.fanta@m...> 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?
At 03:49 PM 5/7/2003, richard_fanta wrote:
Out of the last 50 apps you wrote that did file access, how many involved CD-ROMS/DVDs that were ISO 9660 filesystems?
All of the commercial apps I've done for over ten years have to run from ISO 9660 filesystems (among others). The bug reports remind me of this if I forget. --Beman
At 03:49 PM 5/7/2003, richard_fanta wrote:
Out of the last 50 apps you wrote that did file access, how many involved CD-ROMS/DVDs that were ISO 9660 filesystems?
All of the commercial apps I've done for over ten years have to run from ISO 9660 filesystems (among others). The bug reports remind me of
--- In Boost-Users@yahoogroups.com, Beman Dawes <bdawes@a...> wrote: this if I
forget.
--Beman
Point well taken, but this would probably be expected of digital mapping applications. [I'm sure you've done a lot more, too.] No one is suggested precluding the use of ISO 9660 filesystems, and I don't see how adding "last access" time to the Boost filesystem library would do that. I'm sure that something reasonable could be agreed for "last access" time there, while also accomodating the very common (and I would argue greater volume) of applications that use read/write Posix and Windows filesystems. I recently read an article summarizing an interview with you (Beman). In it you had stated a highly laudable goal of creating a set of C++ libraries to make it competitive with those available in Java, Python, etc. IMO, to make C++ competitive in this way, you have to make it very easy for folks to do basic things that they expect to be there (such as what we've been discussing here). As a user, having to augment C++ libraries fairly often to meet common needs is an annoyance (as a relative C++ newbie current lacking the skill of many here, it's hard to preserve the same style as Boost) that makes me want to go elsewhere (e.g. back to Java). Also, again (currently ;^) lacking mastery to make such additions cross-platform, my app will likely fail in that regard too, hence losing one of the principle benefits of Boost. Neither of these is a good thing, and both cost time.
At 10:03 AM 5/8/2003, richard_fanta wrote:
As a user, having to augment C++ libraries fairly often to meet common needs is an annoyance ... that makes me want to go elsewhere (e.g. back to Java).
I certainly agree with you - C++ users would benefit from more high quality portable libraries. Maybe we can do something about that. Get something started. Let's see, what can we call it? How about... Boost? <g> Seriously, both Boost and the C++ committee's Library Working Group are committed to making more high-quality C++ libraries available, and it seems to be working. Witness the standard library Technical Report now being firmed up. You and other users can help by participating. You don't have to develop libraries to help - just post something on the mailing list, or submit a formal review of new libraries. Tell others about Boost. Every little bit helps. Thanks, --Beman
richard_fanta wrote:
Even if the volume is read-only from one machine, it might still help to know when the file was last altered.
Isn't this last modified time? NT reports 3 times: Created, Modified and Accessed. I would assume that ISO9660 supports modified time. What about other OSes? AFAIK, last access time on NT is read or write access time. Russell
"Ben Hutchings" wrote:
What does that figure refer to, if anything?
richard_fanta wrote:
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 don't understand the question. The topic under consideration is "last access time", so I take your expression "did file access" to mean "used the last access time". Since the latter isn't available for read-only or write-once media, the only possible answer is "none". Looking beyond CD-ROMs, I don't think I've ever written an application that needed the last access time, and given the variation in support, accuracy and precision that Beman mentions, I'm not sure I could come up with one if I tried. Since Windows has been mentioned as an OS that supports them, let me quote from Q245214... "Windows NT and Windows 2000 only updates the Last Access Time every hour for performance reasons." ...although it is stored in the usual very high precision. Actually, that's only true on NTFS. On a FAT file system, the resolution is "one day". Worse, however, is the last access time on my pagefile, which is "06 May 2003, 17:15:04" (the last time I rebooted) because the OS hasn't closed the file yet, so it sees no need to update any of the file times.
richard_fanta wrote:
--- In Boost-Users@yahoogroups.com, "Ben Hutchings" <ben.hutchings@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.
At 06:13 AM 5/8/2003, Peter Dimov wrote:
richard_fanta wrote:
--- In Boost-Users@yahoogroups.com, "Ben Hutchings" <ben.hutchings@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
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"?
Sounds splendid and preferable to compile time failure. Many thanks to you and Peter for adding the clarity that I could not.
participants (6)
-
Beman Dawes -
Ben Hutchings -
Ken Hagan -
Peter Dimov -
richard_fanta -
Russell Hind