Files
beerpsi_fsdecrypt/Cargo.toml
T
JujuforceandClaude Opus 4.8 f4f1f33f8b chore: repoint exfat-fs patch to the v0.1.3-tag-based fix commit
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>
2026-07-06 22:13:24 +02:00

34 lines
1.1 KiB
TOML

[package]
name = "fsdecrypt"
version = "0.1.8"
edition = "2021"
[dependencies]
aes = "0.8.4"
anyhow = "1.0.100"
cbc = "0.1.2"
crc32fast = "1.5.0"
hex-literal = "1.0.0"
indicatif = "0.18.0"
exfat-fs = "0.1.3"
chrono = "0.4.42"
clap = { version = "4.5.48", features = ["derive"] }
ntfs = "0.4.0"
thiserror = "2.0.18"
cipher = { version = "0.4.4", features = ["alloc"] }
[profile.release]
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 v0.1.3 release tag 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 = "dc50d0539246a91f08ad01b565e408f7f94136b6" }