Create repository using: obnam --compress-with=gzip --repository --repository /tmp/backup/ backup "$HOME/"
Try to restore: obnam restore --repository /tmp/backup/ --to=/tmp/restore "$HOME/test"
Error message: ERROR: Invalid repository format version ('x\x9c3\xe5\x02\x00\x00v\x00@') -- forgot encryption?
Either the compression used should be autodetected (maybe saved with metadata?) or the error message should be adjusted (using obnam 0.25)
--xeen
I confirm that I see the bug. And I agree that Obnam should automatically detect when compression has been used and that the error message is awful.
Proposed solution (involving re-formatting the repository, for fun and profit)
- Alter the metadata store to not be filtered
- Alter Repository to not use encryption filter in the metadata files
- Alter HookedFS to allow you to ask that data filters be bypassed
- Alter Repository to ask for bypass on metadata files (format)
- Alter the data filtering hooks to work as follows:
- When filtering for write, the output data format should always be filtername\0data. This chains for each write filter.
- When filtering for read, we read the filter name, apply its inverse on the data and then repeat, chaining until we read \0data (an empty filter name)
Side effects:
- Ordering of filters can change at will, because reading data is always deterministic on the stored data.
- Data is leaked about (at best) the top level filter (which might be encryption).
- Note: Encrypted repositories are obvious anyway so this should not be considered a blocker
- All files increase in size by some number of (at minimum 1) bytes.
- Repository metadata is now not affected by filters, so we can always guarantee to be able to read it and produce useful warnings/errors in case of format mismatches.
Should be fixed in repository format 6