blob: 50c50165b9a8104a391d608f6bcdfb9e457cf9da (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
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)
1. 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)
2. 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
[[done]]
|
