Append shows zip exit status 3 on windows, but binary works as expected about go.rice

[GeertJohan]

Thanks for opening this issue.
Are you sure the files are used from the appended zip? If rice doesn't detect the zip (which afaik is the case when setting zip offset failed), then it will use the files from disk. You can use (*Box).IsAppended() to find out.

Please let me know!

[paradite]

Hi, I have transferred the binary .exe file to another computer and tested it, it worked.
Also, it has roughly the same size as the binary generated using the embed-go method

[paradite]

let me try (*Box).IsAppended()

[GeertJohan]

Cool. And, the embed-go generated files are removed from the build for the appended version?

[paradite]

(*Box).IsAppended() returned true.
Actually I did not run the embed-go version on another computer

[GeertJohan]

I think I know what's going on here.. What version of Go are you using?

[paradite]

go version go1.4.2 windows/amd64

[GeertJohan]

Oh hmm, this is really strange... Can you share the commands you're executing?

[paradite]

Inside src/app, I executed

rice embed-go
go build

I waited for 1 hour and got a working binary, then I installed the GNU Zip from the link you provided, after setting the PATH, I executed

go build
rice append --exec app.exe

[GeertJohan]

Ah okay. So the files you're embedding are probably very large.. I guess the compiler had to use swap to load all data into memory (which caused a long compile time). I don't recommend using embed-go with large files.

So just to be sure: the files generated by embed-go were removed before the go build for the appended version?

I can't think of anything else causing the exit code 3..
The zip tool is used to set the offset at which the zip is located. Go1.5 will support setting the offset as part of archive/zip. But that's not being used by rice yet. But when go1.5 is out I will add it to rice and then this error will definitely be gone.

[paradite]

how do I know what files are generated by embed-go?
If you are taking about the .go files, yes I have manually deleted them.

[paradite]

I have also tried changing a javascript file and append again, the changed javascript was loaded during the execution of the binary so the append did work.

[GeertJohan]

Yes the .rice-box.go files. Those can also be removed by running rice clean inside src/app.

And if you change the javascript file locally, but don't append. You get the older version that was appended earlier?

If so then the append worked fine. It's still really strange that an error is returned, afaik that didn't happen before. The exit code description is:

a generic error in the zipfile format was detected. Processing may have completed successfully anyway; some broken zipfiles created by other archivers have simple work-arounds.

So maybe we can ignore exitcode 3 safely. Maybe the zip created by archive/zip doesn't conform completely to GNU zip's standard and triggers this error?

[paradite]

Yes. Locally changed javascript files do not affect the already appended binary.
Maybe it is the nature of the files that I am trying to append? I have a few font files in various formats like otf, eot, ttf, woff, woff2, etc.

[GeertJohan]

Well that shouldn't affect the zip format ofcourse..
I can't test this as I don't have a windows machine. But can you maybe try appending a box with only a .txt file and see if the error still occurs?

[paradite]

Yes. The error still occurs. The only file appended was a simple txt file.

[GeertJohan]

Do you think it's a good idea to catch exit code 3 and print a warning instead? Something like "Zip exited with code 3. [code 3 description here]. Please confirm that the append was successful." ?

I'll also keep this issue open until go1.5 is released and rice can use SetOffset instead of calling (GNU) zip.

[paradite]

Seems like I am the only one getting this error, Maybe wait and see if there are other people also having the same issue?
Meanwhile this thread can help people who have the error code.

[GeertJohan]

👍

[GeertJohan]

@paradite Are you still experiencing this problem?

[paradite]

Hi, I am no longer working on the project so I have no further information to provide.

[GeertJohan]

Ok, then I'll close this issue.

[at15]

I guess this problem is the same as matrixik mentioned in #4

D:\Golibs\forks\src\github.com\pksunkara\alpaca>zip -A alpaca-full.exe
zip warning: central dir not where expected - could not adjust offsets
zip warning: (try -FF)

zip error: Zip file structure invalid (alpaca-full.exe)

I am using git bash on Windows10 and got the same problem when using append zip. Though zip -A failed, the binary is working as expected.