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:
- Empty sparse files (size = 0), previously did not have any data or
sparse block streams in the backup stream. Now, they will have a
data stream with size = 0, and no sparse block streams.
- Sparse files with a single allocated range (e.g. a normal file that
has the sparse attribute set) previously would not show as sparse in
the backup stream. Now, they will show as sparse.
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>
Since Go 1.6, archive/tar has gained public support for custom PAX
Records, so there's no need to maintain a fork of this library anymore.
We do end up with a fork of the PAX timestamp parsing/formatting
functions, but they are much less likely to change.
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
This removes the MSWINDOWS.* time fields and uses PAX times directly. I
didn't previously realize that PAX times could be negative, which
eliminates the need to store Windows times in a different format.
This also uses the LIBARCHIVE.creationtime field for creation times to
match OS X behavior.
Kevin Parsons