Unable To Locate EOCDR

[sylv256]

https://github.com/SylvKT/sylv-api/blob/1f5ffd63bf0c95c5c2c16b4b54b4c92ea55ef981/src/task/retrieve_jar.rs#L109 This fails to read the zip file here with this error:

ZipError(UnableToLocateEOCDR)

I'm not sure why this is happening or what I can do about it, but it opens fine in Ark.

Operating System

Linux 6.3.6-arch1-1

[Majored]

I'm not personally getting an UnableToLocateEOCDR error with 0.0.15 on macOS (https://imgur.com/l5jGjhE). Are you sure the file you're downloading is getting properly saved?

[sylv256]

It's possible that it's trying to read the file before it's saved. I'll have to do more testing. However, it's only those specific files.

[sylv256]

After some tinkering, I've managed to somehow fix it. I don't know why this works, but it does. This must've been user error. I'm still going to investigate what I did differently. https://github.com/SylvKT/sylv-api/blob/29c7790e36f035d5d5055062fd662aef62f3a543/src/task/retrieve_jar.rs#L207

[sylv256]

So, it seems that the error still persists, but it's somewhat random. I've made it wait for one second now, but it doesn't seem to help.

[sylv256]

This may be related to #70

[sylv256]

Okay, so I made a test that you can try. I want to see if this happens on other systems at all. Try with these jars: minecraft-comes-alive-7.5.3+1.20-universal.jar clutter-1.20-0.3.6.jar spark-1.10.42-fabric.jar wynntils-0.0.3-alpha.89-quilt.jar This may just be an implementation bug (my fault), but I'm not exactly sure what it is.

[mobad]

Okay, so I made a test that you can try. I want to see if this happens on other systems at all. Try with these jars: minecraft-comes-alive-7.5.3+1.20-universal.jar clutter-1.20-0.3.6.jar spark-1.10.42-fabric.jar wynntils-0.0.3-alpha.89-quilt.jar This may just be an implementation bug (my fault), but I'm not exactly sure what it is.

@SylvKT I've noticed that on https://github.com/SylvKT/sylv-api/blob/e57f877ee73b8b2b4ef379eb1b81d3c07cb4cc12/src/task/retrieve_jar.rs#LL78C20-L78C20 it's using file.write() which isn't guaranteed to write the entire buffer (https://docs.rs/tokio/latest/tokio/io/trait.AsyncWriteExt.html#method.write), I think it needs to use write_all.

To verify you can log the response of write and the size of the buffer to see if they match. Or you save the downloaded jars can you try opening them in a normal zip program.

But I'd recommend using something like https://stackoverflow.com/a/74283625 so it doesn't have to save everything in memory and write to a file, it'll just write bytes in chunks as they are downloaded.

[sylv256]

Okay, so I made a test that you can try. I want to see if this happens on other systems at all. Try with these jars: minecraft-comes-alive-7.5.3+1.20-universal.jar clutter-1.20-0.3.6.jar spark-1.10.42-fabric.jar wynntils-0.0.3-alpha.89-quilt.jar This may just be an implementation bug (my fault), but I'm not exactly sure what it is.

@SylvKT I've noticed that on https://github.com/SylvKT/sylv-api/blob/e57f877ee73b8b2b4ef379eb1b81d3c07cb4cc12/src/task/retrieve_jar.rs#LL78C20-L78C20 it's using file.write() which isn't guaranteed to write the entire buffer (https://docs.rs/tokio/latest/tokio/io/trait.AsyncWriteExt.html#method.write), I think it needs to use write_all.

To verify you can log the response of write and the size of the buffer to see if they match. Or you save the downloaded jars can you try opening them in a normal zip program.

But I'd recommend using something like https://stackoverflow.com/a/74283625 so it doesn't have to save everything in memory and write to a file, it'll just write bytes in chunks as they are downloaded.

Using write_all seems to have fixed the issue. Thank you! Also, sorry for opening an invalid issue.