Some curious happenings led to the configuration and membership of the dm-devel mailing list getting wound back to its state in 2004 just over a week ago. It was restored yesterday, but you might want to look at the list archives to check for any messages you missed: https://listman.redhat.com/archives/dm-devel/2022-August/date.html Longer version. In 2001, mailman introduced some code to change the format in which it stored its list information. It took a few years for this to reach deployed distros. It stored the new data for each list under a new filename. Its code looks first for the new file and if it's not there, uses the old one and converts it into the new format. After it has run, the new file will be present so it will just use that from then on. Crucially, if the new file is present but it fails to read its contents successfully, it also falls back and uses the old file if it can. (I'm guessing this was so it could handle interruption during conversion transparently.) The old file was still present for the dm-devel mailing list, and after a reboot on 11th August, the system was unable to read the current file (and its backup) and fell back to using the file from 2004, reconverting it! People started reporting some odd problems with the mailing list but it took several days for us to realise what was going on. We don't know the root cause of the corruption but are continuing to investigate. Lessons so far: 1. If you code a transparent upgrade mechanism, make sure it can only get triggered once, so it cannot repeat itself at a random time many years later. 2. If you get an error processing a data file, it might be better just to stop rather than to assume continuing on with an older copy will be just fine. 3. Make full use of atomic filesystem transactions when updating files and don't disregard the need to flush in all the right places. Alasdair -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
