Proposal about the file system

Anything QL Software or Programming Related.
User avatar
Giorgio Garabello
Gold Card
Posts: 277
Joined: Tue Jun 30, 2015 8:39 am
Location: Turin, Italy
Contact:

Proposal about the file system

Post 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


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Proposal about the file system

Post 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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Proposal about the file system

Post 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.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Proposal about the file system

Post 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


User avatar
Giorgio Garabello
Gold Card
Posts: 277
Joined: Tue Jun 30, 2015 8:39 am
Location: Turin, Italy
Contact:

Re: Proposal about the file system

Post 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?


User avatar
NormanDunbar
Forum Moderator
Posts: 2251
Joined: Tue Dec 14, 2010 9:04 am
Location: Leeds, West Yorkshire, UK
Contact:

Re: Proposal about the file system

Post 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.


Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts

No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Proposal about the file system

Post 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.


Per
dont be happy. worry
- ?
User avatar
Giorgio Garabello
Gold Card
Posts: 277
Joined: Tue Jun 30, 2015 8:39 am
Location: Turin, Italy
Contact:

Re: Proposal about the file system

Post 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


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Proposal about the file system

Post 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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Proposal about the file system

Post 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.


Post Reply