I don't see any dangers using a field for the purpose intended by the OS designers, at least if the programs are used and programmed in a proper way. (BTW, DEC VMS does it in exactly in the same way, so the concept can't be all that wrong...)
Giorgio Garabello wrote:I try to explain it with a simple example:
I am a hypothetical QL user and I have been using the HARDBACK program for 5 years.
I read about the WINBACK program and decide to try it.
I unload it, install it and make a backup.
For some reason I decide that I do not like it and I want to continue using HARDBACK. Unfortunately, at this point the backup dates could have been all compromised.
That's an easy fix. With every incremental backup, store the timestamp when it was finished. Request the last incremental backup to check when doing a new increment. If you find any backup timestamp newer than the last increment, revert back to a full backup.
Remember, in a multitasking system you need to have the backup timestamp per file
, otherwise you might miss changes to files that were done while the backup runs (and, given the storage media of the time, backup was most probably done to floppies, so backing up a 40Meg hard disk could takke some time...
Giorgio Garabello wrote:The most correct choice is to use an internal database to record information, not the file system (even if allowed)
It is conceptually wrong that a single application can take possession of a data that should be managed only by the operating system, as it is a general datum.
I disagree the backup date is a general datum. It belongs to the program that did the backup (as I think you have proven with your example above). Remember this specification dates back to 1985, when hard disks for the QL didn't even exist - Building extensive backup support like you propose with an internal database that would maybe have been used by 0.5% of the users into a small system that the QL was at that time would very probably have been severe overkill.