15 Commits
Author SHA1 Message Date
JujuforceandClaude Opus 4.8 521736aa58 chore: release version 0.1.9
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-06 23:34:43 +02:00
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
JujuforceandClaude Opus 4.8 622aa537ee fix: extract exFAT OPTION containers that contain empty files
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>
2026-07-06 22:06:38 +02:00
JujuforceandClaude Opus 4.8 9c2821ddab chore: bump version to 0.1.8
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-28 11:18:27 +02:00
beerpsi 4c3ebd9771 fix IV derivation 2026-01-21 09:26:00 +07:00
beerpsi 362fb91ff7 feat: also extract exfat without saving intermediary exfat image 2026-01-21 09:05:10 +07:00
beerpsi 023627426e Release 0.1.5 2026-01-20 18:02:42 +07:00
beerpsi 0c4a521bc2 feat: directly extract VHD for apps and packs 2026-01-20 18:00:19 +07:00
beerpsi 8db2d1e71b port buffering to exfat extraction 2025-11-04 13:05:10 +07:00
莯凛 8c5998a85c perf-buf-size (#2)
Increased IO throughput when laying out VHD file

`std::io::copy` will only setup an 8KiB stack buffer, which results sub optimal performance when passing `File` directly.

Reviewed-on: https://gitea.tendokyu.moe/beerpsi/fsdecrypt/pulls/2
Co-authored-by: 莯凛 <mokurin000@gmail.com>
Co-committed-by: 莯凛 <mokurin000@gmail.com>
2025-11-04 05:53:17 +00:00
beerpsi 8b34b87732 feat: NTFS support 2025-07-17 19:57:03 +07:00
beerpsi 7bcd2efb06 Release 0.1.2 2025-07-16 23:45:13 +07:00
5d1e0ca908 feat: exfat content extraction (#1)
Co-authored-by: jujuforce <jujuforce@gmail.com>
Co-authored-by: beerpsi <beerpsi@noreply.gitea.tendokyu.moe>
Reviewed-on: https://gitea.tendokyu.moe/beerpsi/fsdecrypt/pulls/1
Co-authored-by: jujuforce <jujuforce@noreply.gitea.tendokyu.moe>
Co-committed-by: jujuforce <jujuforce@noreply.gitea.tendokyu.moe>
2025-07-16 15:49:11 +00:00
beerpsi 252ea9c797 Release 0.1.1 2024-07-22 10:13:58 +07:00
beerpsi dbbe287b1c initial commit 2024-07-21 23:59:02 +07:00