[LIMITATION] PFSC zero-tail: folder→FFPFS include zero-padding when decoded, causing console read failures

[RenanGBarreto]

Summary

Some PFSC-compressed files served from mounted game backups appear correct at the start but include extra zero bytes appended up to the next 64 KiB block boundary. That zero-padding causes checksums and console reads to fail for certainassets (fonts, cinematics, some animation families), even though images may verify locally.

Observed symptom

• Downloads return the original file bytes followed by zero bytes up to the next PFSC logical-block boundary.
• Affected assets vary by path and family; the problem is not limited to a single file extension.

Scope / when this happens

• This is not a problem for all PFS images. It occurs specifically when converting a game backup folder in a single-pass (folder→FFPFS) flow with PFSC compression enabled. Images produced using a container/wrapper-based flow (e.g., FFPFSC) are not affected by this single-pass-with-compression failure mode.

Likely cause (high level)

• A mismatch in PFSC size/offset semantics between the writer and reader: the producer encodes or declares sizes one way and the consumer expects block-aligned lengths or interprets offsets differently. As a result, the reader may reconstruct padded logical blocks and not trim them back to the original file length, producing zero tails.

Impact

• Users who convert raw game backup folders directly into compressed FFPFS images (single-pass with compression enabled) can create images that pass local verification but fail when read on the console or other readers for a subset of files.
• The issue is dataset-specific (mixed safe/unsafe samples), so blanket extension-based rules are unreliable.

Short-term mitigation (practical)

• Prefer using the container/wrapper flow (FFPFSC) rather than single-pass folder→FFPFS with compression when packaging game backups. The container-based format avoids this failure mode while preserving compression where appropriate.
• A orange warning message was added in the mkpfs output to alert users. (Warn when packing game/app folders directly with compression enabled or invalid configs #48)

---

ℹ️ At this moment, there is no known solution for this issue. Preffer to use FFPFSC over Compressed FFPFS.

[sunnyqeen]

the problem is

MkPFS/mkpfs/pfs.py

Line 1097 in 895820d

data_length=block_count * logical_block_size,

MkPFS/mkpfs/pfs.py

Line 1489 in 895820d

data_length=block_count * logical_block_size,

the data_length is set with padded size, when mounted on ps5, you can see the file size is also padded, not the origin filesize.
Easy reproduce with compressing a single file that is not 64KB aligned, and mounting with micromount.
Check the size with ftp.

[RenanGBarreto]

Yes, but I tried changing it to the actual size, and it didn't work. Are you sure that would fix it? I can try again later

[sunnyqeen]

not fixed. I mean the file size is correct if changed, reading the file will fail.
ps5 firmware seems take that as file size.

[RenanGBarreto]

not fixed. I mean the file size is correct if changed, reading the file will fail. ps5 firmware seems take that as file size.

Yes. I did another expriment. Fixing the file size in the header solves the zero padding but PS5 can not read some files and games crashes