[Dump-announce] Dump/restore 0.4b50 release

[Tim W. <sou...@wo...>]

Hi everyone,

The 0.4b50 release of dump/restore has been published. (The date in the 
manpages says "version 0.4b50 of 22 Mar 2025". I didn't expect to get 
time to publish until the weekend but all the tests completed last night 
and I got a bit of spare time today so you get it early)

For most people there's little of interest here unless you're having 
problems restoring old dumps where there's a few fixes:

1. A new command line option --ignore-compression-flag-for-0.4b45-dumps 
for restore that allows dumps writen with "compression" by v0.4b45 to be 
restored.  This flag should not be used in any other context - it won't 
help!  Thankyou to Greg for his update on bug #169 which lead to this.

2. The Archive file was not padded to a whole number of tape blocks. 
This means that 0.4b49 could not use archive files unless they happened 
to be the correct length.

3. Tapes written with compression header bitfields that are not in amd64 
gcc order can now be read. This was supposed to work in 0.4b49 but a bug 
meant that it only worked for amd64 gcc ordered bitfields. 0.4b49 
removed the compiler dependency and ensured the bitfields were always 
written in the amd64 gcc order.

There's one bugfix - which has been patched in debian for ages: QFAfiles 
for real tapes always had a zero tape position. I inadvertently dropped 
this completely while bringing in the debian fixes to 0.4b49.  Thankyou 
to Alexander Zangerl for spotting my mistake.


And there's two new command line options to dump:
--filesys-name - which lets you set the text of the dump to replace the 
default "an unlisted filesystem". This is particularly aimed at people 
who dump from snapshots which do not appear in fstab or mtab.

--dumpdates-time - which sets the time of the dump to that supplied on 
the command line instead of dump using the current time when it starts. 
There's a race condition related to dumping from snapshots that this 
resolves (see below for details of the race condition for anyone who 
thinks they might be impacted)


See NEWS for more details of the changes in this release.


I haven't fully tested all the long command line options. They should 
all be documented in the man pages. I'll give a credit in the next NEWS 
file for anyone who finds any where I've made a mistake and it doesn't 
work the same way as the single character option. File a bug on the 
sourceforge page or email me or one of the dump lists.

-------

Race condition related to dump timestamps and snapshots:

Day 1 level 0 dump: (assume this starts at 00:00:00 on day 1)
1. Take a snapshot of the filesystem at D1-00:00:00

A file now changes on the underlying filesystem - this change is not 
visible in the snapshot - the file has the modification time of 
D1-00:00:01

2. Dump starts at D1-00:00:02 and writes this timestamp into dumpdates. 
The level 0 dump completes and verifies correctly against the snapshot.


Day 1 level 1 dump: (assume this starts at 00:00:00 on day 2)
1. Take a snapshot of the filesystem at D2-00:00:00

2. Take the level 1 dump. All files that have changes between 
D1-00:00:02 and D2-00:00:00 will be included in the dump. The file with 
the D1-00:00:01 timestamp is missed and never gets included in any 
incremental dump (unless the file changes again)



In order to avoid this issue, --dumpdates-time should be set to the time 
of the snapshot (which will likely be a few seconds earler than dump 
would have written to dumpdates.


N.B.  There are plenty of other issues related to taking a dump of a 
live filesystem that this commandline flag doesn't solve but many of us 
do take snapshots of a live file system to dump it.