Bug in plocate plugin

[jadevries]

Using the plocate file parser class outside of the Dissect context I noticed a bug: (almost) every 32nd path gets appended to the previous path.
While testing with target-query I also could reproduce this behaviour on Debian, Ubuntu and Fedora.

I tested and reproduced this on:
Fedora 39: python 3.12.0 (plocate 1.1.17)
Fedora 40: python 3.12.2 & python 3.9.19 (plocate 1.1.22)
Ubuntu 11.04: python 3.10.12 (plocate 1.1.15)
Debian 11: python 3.9.2 (plocate 1.1.8-2)

plugin function used: https://github.com/fox-it/dissect.target/blob/b1bcb0d89d3b24a9ad7e8150d63ddd6dd30a82a2/dissect/target/plugins/os/unix/locate/plocate.py#L138C21-L138C26

[Horofic]

@JSCU-CNI Have you noticed any similar behaviour on your side? This behaviour does not seem to occur in the related test-cases.

[JSCU-CNI]

Thank you for the fix @Horofic. This seems like an oversight from our end. It is not clear to us as to why the end of a zstd frame does not contain a final null byte. Could that be a bug in plocate's zstd implementation? Reading in chunks and splitting on null bytes seems like a reasonable fix to us for now.

[Schamper]

I have not looked at any plocate code, but I can imagine it's a small optimisation if the decompressed data fits entirely within one frame, otherwise you'd have to move the final path to the next frame just to fit the null byte. Especially if you then decompress into a char[FRAME_SIZE + 1] it shouldn't give you any trouble in C.