Hi could you share how you actually managed to do all of this? I am dealing with this same issue and really need help moving the data descriptor stuff to the file header. Thank you.
On Saturday, May 16, 2015 at 12:06:23 AM UTC-7, Alex Skinner wrote: > > I took a look at this tonight mainly to learn about the zip format spec > since I've never bothered. I used your Go code to create a zip, then tried > to extract with java on linux as I don't have time to fiddle with testing > on Android at the moment. Here is what I found if it's relevant - and it's > very late, so expect errors below - > (I used this page as spec, if that matters - > https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) . > > Using a ZipInputStream, java failed to parse the file with error 'only > DEFLATED entries can have EXT descriptor'. Further checking shows that Go > seems to consistently set bitflag 3(08) in byte 7. The spec says "Note: > PKZIP version 2.04g for DOS only recognizes this bit for method 8 > compression, newer versions of PKZIP recognize this bit for any compression > method." This seems to imply to me that Java is behaving as described in > the above, because the Go version is in fact doing what bitflag 3 implies, > which is putting the data descriptor after the data, but not using > compression method 8. I honestly don't know what benefit this serves, if > any, though. > > The only way I could get java to successfully expand the Go zip was to - > 1 - Change byte 7 to '00' for each file > 2 - Move data in data descriptor into their fields in the file header > 3 - Remove the descriptor signature and descriptor > 4 - Change offset at end of file > > Or, take your Go created zip file(test.zip) and run 'zip -F test.zip > --out fixed.zip' which does all this in my tests. If that resulting file > then works, that may be the reason. If that is in fact the problem, it > should be straightforward to make a local copy of archive/zip and change > this behavior I think. > > Curious to know what you find, > Alex > > On Friday, May 8, 2015 at 9:32:32 AM UTC-4, JohnGB wrote: >> >> I've written some code that creates a .zip file from a number of other >> files (.png in case it matters). The zip file seems to be fine, and I can >> open it on both a mac and windows computer without a problem. However when >> an Android device (using the java.util.zip package) tries to open the file, >> it throws an error that the file is not a .zip file. Given how long >> java.util.zip has been in use, I doubt that the problem is there, and >> assume the issue is with the method that I've used to create the .zip file >> in the first place. >> >> Below (or in play <http://play.golang.org/p/Z8JTIret-K>) is the function >> that I'm using to zip the files: >> >> func createZip(zipDir, zipName string, filesToZip []string) error { >> >> // creat the file to zip the contents into >> newfile, err := os.Create(zipDir + zipName) >> if err != nil { >> return err >> } >> defer newfile.Close() >> >> zipit := zip.NewWriter(newfile) >> defer zipit.Close() >> >> for _, filename := range filesToZip { >> zipFile, err := os.Open(zipDir + filename) >> if err != nil { >> return err >> } >> defer zipFile.Close() >> >> // get the file information >> info, err := zipFile.Stat() >> if err != nil { >> return err >> } >> >> // create a zip header from the os.FileInfo >> header, err := zip.FileInfoHeader(info) >> if err != nil { >> return err >> } >> >> // write the header to the zip file >> writer, err := zipit.CreateHeader(header) >> if err != nil { >> return err >> } >> >> // copy the file to the zip file >> _, err = io.Copy(writer, zipFile) >> if err != nil { >> return err >> } >> } >> return nil >> } >> >> I would appreciate feedback on my code, or suggestions as to where I can >> look for the cause. >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.