Got the following warning message suddenly on a recurring scheduled run of the same backup which ran fine for a long time.
2025-10-03 04:19:51 +02 - [Warning-Duplicati.Library.Compression.ZipCompression.FileArchiveZip-system-io-compression-error]: Failed to create built-in ZIP archive, falling back to SharpCompress InvalidDataException: Number of entries expected in End Of Central Directory does not correspond to number of entries in Central Directory.
version: 2.1.0.5_stable_2025-03-04
linux: debian 13 amd64
job size: 1 TB
target: btrfs formatted disk, nagios says: Scrub started: Tue Sep 30 00:24:01 2025,Status: finished,Duration: 4:47:02,Total to scrub: 2.11TiB,Rate: 131.60MiB/s,Error summary: no errors found
That sounds really scary, given that the zip file is inside the .aes container so it is not possible to modify the file without tripping the AES HMAC. In other words: it appears Duplicati has written a zip file that is defective, and then encrypted it!
If this is a new file, I would suggest running a memory test on the machine that is running Duplicati, and check if the disk health shows any warnings.
If this is an old file, created by an older version of Duplicati, I would write it off as a difference between how the old and new zip library parses the file.
The “Extra” entries can be ignored. This means that the files contain data that is not expected to be there, but it does no harm.
The warning is a faulty check that does not account for blocks that are logically deleted (not being used by any files). The blocks were in use when the index file was created so they are included. This logic is fixed in the latest beta.
That is because the testing marks the files as having been tested (the warning does not mark the file defective), so the next run will randomly test some other files.
You can rewrite the file using the recovery tool and the recompress feature:
This can write a new encrypted file, using the existing one.
You can then replace the existing file with the new file, but you then need to also update the Duplicati local database with the hash and size of the new file (or set them to null and -1).
If you do not update the database, Duplicati will complain saying the files have been tampered with (which is true, but expected in this case).
How can I get the filename of the file that triggered this warning? I can’t see it mentioned in the log.
The storage is btrfs and did complete an integrity check with “success, no bad blocks found”.
I guess it’s come from an older version of Duplicati, as the job has run for quite some time back over years. Given that the backup is not totally hosed, I’d move it to another location and start freshly including regular verification runs as pointed out to me on the other thread. This is a perfect support from you, I’m very happy to learn more about Duplicati.
That is a bit difficult, because of the way the warning is triggered, the code that processes it has no idea what the filename is, so it does not log it.
If you want to find out, you can look at the timestamp of the warning and then the timestamp of the remote operations in the database, and then narrow it down to (ideally) one file.
Yes, but since the error is inside the encrypted file and the file was not rejected, that means that the file was not damaged on the remote storage. A wild guess is that the temporary storage where Duplicati writes the zip file before encrypting it could have introduced this error. In other words: the storage for the temp folder on the machine running Duplicati may have had a fault.
But if this file is from an older version, it is likely that there was an issue with the compression library used at that time, but since files are only occasionally read this issue could have been there for a long time. If you simply switch to using the SharpCompress library for compression, it would most likely also make the error message go away.
With Duplicati 2.1.0.5 and forward, we are using the .NET Zip library which is likely interpreting the headers slightly different than SharpCompress and this triggers the warning.
