resolve end header not found

[wagyourtail]

resolves #933

it appears that with thunderstore app, the end of the zip gets padded with a bunch of 0's after for some reason.
I would guess this is an issue with padding on their buffer that they just write instead of trimming first.

the zip reader doesn't like that

this pr fixes that by ensureing the zips are trimmed

[CLAassistant]

All committers have signed the CLA.

[MythicManiac]

Good find! The current implementation seems to load the entire zip to memory before writing it back to disk, which is potentially a bad idea to do as some profile exports can be quite large. I can't immediately think of a good way to address that, but we might be able to fix how zip creation works on the other mod manager & ensure it doesn't create trailing zeroes at least in the meanwhile.

[wagyourtail]

well. the FsProvider doesn't wrap the fs functions for streaming file content... or fs.truncate. maybe if I add them...

[wagyourtail]

done

[ebkr]

Added a few comments, thanks for the contribution! Sorry for the delayed response.

[MythicManiac]

The real blocker with the PR is that on TMM the I/O implementation is done by a C# plugin, and we can't pass complex types through that IPC layer, including streams I believe. In other words, this has to be implemented in some fashion that avoids passing complex types to/from the FS provider.

One option would be to implement the whole zip preprocessing logic in the FS provider, which we can keep as a stub on the C# plugin since the C# code already is able to handle the zips as is.

[wagyourtail]

The real blocker with the PR is that on TMM

It's fixed here, so I don't see why fixing in on TMM would block this PR seeing as this is the fix for the issue on this end, and doesn't rely on TMM fixing it.

[MythicManiac]

It's fixed here, so I don't see why fixing in on TMM would block this PR seeing as this is the fix for the issue on this end, and doesn't rely on TMM fixing it.

It's because the same code runs on both for a large portion of the core mod install logic to keep mod installs consistent between the two. In other words, we'll need to make similar adjustments to the filesystem provider implementation on TMM as was done here or the build breaks. And as things currently are implemented, I don't think it's possible to do due to the C# interop layer not supporting complex types.

So I'd suggest moving the current sanitizeImportEndHeader functionality to the FsProvider, e.g. as a function called sanitizeZip which takes in a filepath as a parameter and truncates it in-place. That way there's no need to pass complex types through the interop layer on TMM but the fix also works here.

[ebkr]

@wagyourtail For context, r2modman is a git submodule that TMM uses, so the code internally isn't actually modifiable from TMM's end. We use a "provider" that lets TMM override behaviour of certain areas. So by having the code in the provider TMM can avoid using it and use the C# layer which works as intended.