Winback backups are just copies of the files on hard disc. Unless you decide to split a file over a number of floppies, for example. The backup date is when the backup completed.
I expect Jan's Hardback to do a similar thing. So, in your scenario, I have a backup of the file with Hardback, and another with Winback, the file's backup date on the hard drive is the date and time of the most recent of the two.
Problem'? What problem?
I suspect you are overthinking a problem that doesn't actually exist.
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
With the exception of Microdrives (don't know about RAM drives), The file headers are only stored in the Directory.
There are 64 unused bytes at the start of every stored file (where the file header is also stored on MDV's). These bytes are usually unavailable, but could they be made available with a device driver update (device level 4?). Maybe accessed by a new #3 system trap?
Older systems would not be affected, as they would not recognise the new system trap. They would just not be able to use any of the information stored.
I realise that that there may be problems with things like COPYing files, ensuring that this 64 byte block is also copied.
The redundancy that file header space is duplicated in the first 64 bytes of the raw representation of the file and the file header in the directory file is specific to the QL5A/B and similar file systems. Systems that use a different disk file system might not necessarily have that duplication (ATR file system, DOS file systems, the Q-Emulator native file format...).
Note I have not seen a specification yet that said
"You don't store the header of a file in the first 64 bytes of the file itself on a QLWA disk, but instead store it in the directory" although most drivers I've seen do it that way. That is an implementation detail of the driver. A driver could also decide to really duplicate the 64 bytes to both the file and the directory.
With quite some bytes unused as of yet in the "normal" file header, I am also a bit concerned whether it's worth the effort to implement drivers for access to "only" 64 spare bytes per file. Also, copying a file from disk to microdrive would destroy that extra information.