When extracting GNU sparse tar entries, System.Formats.Tar preallocates using the entry’s logical size rather than the packed data size. That means a small sparse archive can cause a large disk reservation during extraction, which is surprising on small or quota-limited volumes.
I traced this through GnuSparseStream.Length returning the declared real size and TarEntry.CreateFileStreamOptions using that value for PreallocationSize. The extractor then writes the sparse content normally, so the output file is expected, but the preallocation behavior can still create unexpected storage pressure.
Minimal repro:
- Create a GNU sparse tar entry with a very small payload and a large declared
GNU.sparse.realsize.
- Extract it with
TarFile.ExtractToDirectory(...) or TarEntry.ExtractToFile(...).
- Observe that extraction reserves space based on the expanded size, not the packed archive size.
This seems like a behavior/documentation issue, or possibly something to reconsider for sparse entries, since it can make extraction more expensive than users expect.
When extracting GNU sparse tar entries,
System.Formats.Tarpreallocates using the entry’s logical size rather than the packed data size. That means a small sparse archive can cause a large disk reservation during extraction, which is surprising on small or quota-limited volumes.I traced this through
GnuSparseStream.Lengthreturning the declared real size andTarEntry.CreateFileStreamOptionsusing that value forPreallocationSize. The extractor then writes the sparse content normally, so the output file is expected, but the preallocation behavior can still create unexpected storage pressure.Minimal repro:
GNU.sparse.realsize.TarFile.ExtractToDirectory(...)orTarEntry.ExtractToFile(...).This seems like a behavior/documentation issue, or possibly something to reconsider for sparse entries, since it can make extraction more expensive than users expect.