Merge pull request 'fix: extract exFAT OPTION containers that contain empty files' (#10) from jujuforce/fsdecrypt:fix/exfat-empty-file-extraction into trunk

Cargo.lock

@@ -481,8 +481,7 @@ dependencies = [
 [[package]]
 name = "exfat-fs"
 version = "0.1.3"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "5cbdfa8ecf36ab2341032974d3644a56f1e40c9da3b643118492cf97f357f3c5"
+source = "git+https://github.com/jujuforce/exfat-fs.git?rev=7067f6afe3c21d9c737288475b29e5dae790e206#7067f6afe3c21d9c737288475b29e5dae790e206"
 dependencies = [
  "bitflags",
  "bytemuck",

Cargo.toml

@@ -21,3 +21,13 @@ cipher = { version = "0.4.4", features = ["alloc"] }
 lto = "thin"
 codegen-units = 1
 strip = "none"
+
+# exfat-fs 0.1.3 rejects empty (zero-length) files/dirs: its
+# StreamExtensionEntry::valid() treats FirstCluster < 2 as invalid, but an
+# empty file legitimately has FirstCluster = 0 / DataLength = 0. That aborts
+# the whole extraction the moment an OPTION container contains any 0-byte file.
+# Until the fix lands in a published release, override with a fork branch that
+# is the 0.1.3 release plus only that one-function fix (identical public API).
+# See https://github.com/jujuforce/exfat-fs/tree/v0.1.3-empty-file-fix
+[patch.crates-io]
+exfat-fs = { git = "https://github.com/jujuforce/exfat-fs.git", rev = "7067f6afe3c21d9c737288475b29e5dae790e206" }