The exfat-fs empty-file fix branch was rebuilt on top of the upstream v0.1.3
release tag (instead of an orphan commit) so it has proper shared history and
reads as a clean "1 commit ahead of v0.1.3". Update the pinned rev accordingly;
tree and behavior are identical (v0.1.3 + the one-function fix).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
exfat-fs 0.1.3's StreamExtensionEntry::valid() rejects any entry with
FirstCluster < 2, but a zero-length file (or empty dir) legitimately has
FirstCluster = 0 / DataLength = 0 per the exFAT spec. The parser returned
InvalidStreamExtension and aborted the *entire* directory tree the moment it
hit one empty file, so real OPTION (.opt) containers failed to extract with:
WARNING: Failed to extract exfat contents: InvalidFileEntry(InvalidStreamExtension)
even though unsega/7-Zip read them fine.
0.1.3 is the latest published release and its `main` has an incompatible
public API, so override the dependency via [patch.crates-io] with a fork
branch that is the 0.1.3 release plus only the one-function fix (gate the
cluster check on DataLength: 0 -> FirstCluster must be 0, else >= 2).
Regenerate the synthetic OPTION fixture with a zero-byte file so tests/e2e.rs
reproduces the bug: without the patch it fails with InvalidStreamExtension;
with it, extraction succeeds. Verified against a real 191 MB OPTION container
(1602 files / 1217 dirs, empty file written as 0 bytes) and the full suite.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>