Closed kevpar closed 2 years ago
I'm new to this code and the backup protocol, but from my understanding, this LGTM
@katiewasnothere is there something that should be expanded upon that would be helpful here? I had never touched this code either, and had to learn what it was doing. I tried to clarify the reasoning for the new behavior in my comments.
@katiewasnothere is there something that should be expanded upon that would be helpful here? I had never touched this code either, and had to learn what it was doing. I tried to clarify the reasoning for the new behavior in my comments.
No, it made sense! I wrote that more to say that while it looks good to me, since I'm not super familiar with the code, I could potentially be missing small details/issues.
A recent OS change altered how sparse files are represented in backup streams. This caused backuptar to no longer work with certain files. The specific behavior that changed is as follows:
The old backuptar behavior assumed that if the sparse flag was set on the data stream, then there would always be a set of sparse blocks following. These changes break this assumption, and so require special handling.
It is unsupported to have a data stream, marked sparse, that contains file content AND a series of sparse block streams following. As far as I can tell this is not a valid case for backup streams.
This change also cleans up some code and error messages, and expands on the test coverage for backuptar.
For more information on backup stream format see: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-bkup/f67950c8-d583-469a-83dd-c4ff4cedf533
Signed-off-by: Kevin Parsons kevpar@microsoft.com