Page 1 of 2

Proposal about the file system

Posted: Tue Oct 09, 2018 4:02 pm
by Giorgio Garabello
In the header file we have the backup date field from what is not used.
Can not be used to insert the file creation date?
What do you think?

Giorgio

Re: Proposal about the file system

Posted: Tue Oct 09, 2018 4:55 pm
by tofro
Giorgio,

the file backup date is not used by the system.

Various backup programs do, however, use it for the intended purpose (compare modification date with backup date and decide a file does not need to be part of an incremental backup in case the former is earlier than the latter). Any change in meaning would render them unusable.

Tobias

Re: Proposal about the file system

Posted: Tue Oct 09, 2018 5:23 pm
by NormanDunbar
Evening Giorgio,

the backup date in the file header is used by WinBack, to store the date the file was last backed up and to compare with the "last modified date" when checking whether or not the file needs backing up. I suspect other backup utilities do a similar thing, but I did it first! ;) ;) ;)

Cheers,
Norm.

Re: Proposal about the file system

Posted: Tue Oct 09, 2018 11:32 pm
by janbredenbeek
NormanDunbar wrote:Evening Giorgio,

the backup date in the file header is used by WinBack, to store the date the file was last backed up and to compare with the "last modified date" when checking whether or not the file needs backing up. I suspect other backup utilities do a similar thing, but I did it first! ;) ;) ;)
I wrote HARDBACK which does the same. The original files are dated 1 July 1989 (don't believe the archive on Dilwyn's site that says 2042 :) ). Which is just about three weeks after I got my Miraculous Winny...

Jan

Re: Proposal about the file system

Posted: Tue Oct 09, 2018 11:47 pm
by Giorgio Garabello
janbredenbeek wrote:
NormanDunbar wrote:Evening Giorgio,

the backup date in the file header is used by WinBack, to store the date the file was last backed up and to compare with the "last modified date" when checking whether or not the file needs backing up. I suspect other backup utilities do a similar thing, but I did it first! ;) ;) ;)
I wrote HARDBACK which does the same. The original files are dated 1 July 1989 (don't believe the archive on Dilwyn's site that says 2042 :) ). Which is just about three weeks after I got my Miraculous Winny...

Jan
As already asked on the ML
why a so dangerous choice?

Re: Proposal about the file system

Posted: Tue Oct 09, 2018 11:56 pm
by NormanDunbar
In my case, because that's exactly what the backup date is for, and how it's documented.
I don't see what's dangerous about it though.

Cheers,
Norm.

Re: Proposal about the file system

Posted: Wed Oct 10, 2018 1:15 am
by pjw
I wrote a file backup system for transporting incremental changes to file sets. I used FBKDT for storing a CRC of certain files as a check for renames. However, in the end I decided not to use this system location and used a control file instead, so as not to introduce incompatibilities with future system updates ;)
Anyway, the location was already taken by DP, IIRC, to store the real lengths of their compressed file format for EyeQ(?)
Personally, I dont think any existing non-system use of this location should be a hindrance to future system wide improvements.. After all, the authors are still alive and kicking, and presumably their source code is available to make any necessary changes if needed.

Re: Proposal about the file system

Posted: Wed Oct 10, 2018 7:58 am
by Giorgio Garabello
NormanDunbar wrote:In my case, because that's exactly what the backup date is for, and how it's documented.
I don't see what's dangerous about it though.

Cheers,
Norm.
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.

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 do not know why this field was originally defined, perhaps it could have made sense in the 80s but certainly today it has no sense of existing.

Giorgio

Re: Proposal about the file system

Posted: Wed Oct 10, 2018 11:42 am
by tofro
Giorgio,

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.

Tobias

Re: Proposal about the file system

Posted: Wed Oct 10, 2018 2:45 pm
by RWAP
tofro wrote:
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.
There is also KnightSafe - I am not sure how that handles backups and incrememtal backups. If switching between WINBACK and KnightSafe (for example), you might need a simple utility which resets all of the backup timestamps to 0, as that would overcome any problems where the two backups are in different formats and therefore the backup date might cause confusion.