You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe I may have found another potential explanation: some archives are made on Debian with fsarchiver built in that specific environment (bullseye - same fsarchiver commit);
if I try archinfo with fsarchiver built on Ubuntu, I get the error.
If I try archinfo with fsarchiver built on Debian, I get no error.
Does the archive-id depend on some fsarchiver binary specific UUID or equivalent random number?
In other words, is it compulsory to extract an archive with the same fsarchiver that was used to make it?
Ubuntu 20.04
fsarchiver 30c9e23
FAT32 file-system archived with fsarchiver 0.8.6-git (20191230):
No such issue with Ext4 file-system archived with fsarchiver 0.8.6-git (20191230):
No such issue with FAT32 file-system archived with fsarchiver 0.8.6-git --1 year ago--:
The archives are created with the command:
I'm positive no archive can be corrupted as they are checked regularly.
This issue is most probably linked to this unsolved one.
Something have probably been changed in the code between 2019-03-21 and 2019-12-30 in the way the FAT32 file-systems are handled.
The text was updated successfully, but these errors were encountered: