advanced sparse file support

[ThomasWaldmann]

See there for the basics: jborg/attic#256

The current state in borg is that it has simple sparse file support (meaning that it does nothing special on "create", but offers the option to deal with all-zero chunks in 2 ways at "extract" time: a) write zeros to disk (default) b) just "seek" in the output file, creating a hole in a sparse file (--sparse).

See the original attic ticket: while this always works correctly from a logical file content perspective, it is not extracting the data and hole sections of files exactly as they were when the archive was made.

Precise reproduction would need saving the type (data vs hole), length and in case of data, the binary data for each section in the file. SEEK_DATA and SEEK_HOLE support this.

Attic (and current Borg) just has a simple stream of binary file contents and as there is no type/length yet, it can't be added in a compatible way on the file contents level.

Update: I put a bounty on this. It is for implementing sparse file support at archive creation time (seeking over holes [not reading them as zeros], storing which parts of a file are holes / contain data) and reproducing sparse files hole/data layout precisely at archive extraction time.

[ThomasWaldmann]

Just to keep a vague idea:

If the different layers in borg would communicate a bit more (like the compression method being flexibly given by upper layers and the decompression result being able to tell whether its result is data that needs to be written to disk or just a sparse hole that needs to be "seeked"), the adv. sparse file support could maybe be just a special kind of "compression/decompression".

sparse compression would just store: 2 type bytes for "sparse", 8 bytes length of hole
sparse decompression would result in: hole=True, hole length
other decompression would result in: hole=False, data

instead of a hole=X value, it could be also an entry in a more generally useful meta dict, see #765.

[ThomasWaldmann]

Advanced sparse file support would also save some time for archive creation as it does not have to read all these zeros in the sparse wholes (simple sparse file support just reads them all).

[enkore]

The less involved feature, not having to chunk-HMAC hole contents is handled in #1354