-unzipfile- command yields an error message (invalid CEN header)

[Adam Sadi]

Dear Statalisters,

I'm working on some heavy Stata files with colleagues on a common Dropbox. At some point in our do-file, we need to extract some files contained in a zip file because one of them is too heavy for the Dropbox. The code is :

unzipfile "$inp/Database", replace

With $inp being a shortcut for my directory. I get the following output :

invalid CEN header (bad compression method: 9)

extracting XXXXXXXX/Database.zip incomplete
total processed:  0
        skipped:  0
      extracted:  0
r(692);

end of do-file

I hid the details on my directory but there is no mistake regarding the macro $inp. I am really bad in informatics and I have no clue about what a CEN header means. There are supposed to be two datasets in the zipfile but for some reason Stata do not seem to recognize it. It works perfectly fine when I open it on softwares such as WinRar for example.

I would not want to open a zip file from a stranger, so I won't attach any file to this thread. Did anyone face the same issue and might help me finding a solution? Does this problem have to do with me working on a Dropbox ?

Regards,

Adam

[Jared Greathouse]

This is a python problem. Download python and do it like that (seriously, this is the solution, I know cuz I've had similar experiences)

[Hemanshu Kumar]

Jared Greathouse could you explain that? When I looked into the code for unzipfile.ado, it looked like the core functionality was being handled with a Java call, and so it looked to me like a Java problem.

Also, a workaround might be to use the shell command, and then just use a command line call to WinRAR, since that seems to work fine for Adam.

[Jared Greathouse]

Yeah I should've been more specific, I mean that the SOLUTION is found in Python, not that the problem is in Python literally. I don't remember the circumstances, but I once had to unzip I file in Stata using Python because for WHATEVER reason Stata's unzip just wasn't playing nice with it.


I remember commenting inmy do file at the time "Yes, you have to use Python because Stata's is stuuuuuupid" or something like that, I never did find what the real issue was, I just know Python solved it Hemanshu Kumar

[Sergiy Radyakin]

Yeah I should've been more specific, I mean that the SOLUTION is found in Python, not that the problem is in Python literally. I don't remember the circumstances, but I once had to unzip I file in Stata using Python because for WHATEVER reason Stata's unzip just wasn't playing nice with it.


I remember commenting inmy do file at the time "Yes, you have to use Python because Stata's is stuuuuuupid" or something like that, I never did find what the real issue was, I just know Python solved it Hemanshu Kumar

Perhaps related to this: https://www.statalist.org/forums/for...nzipfile-fails ? Under version control Stata falls back to the unzipping method, which doesn't handle the archive, which it could otherwise handle without version control.


Adam Sadi , try to run your diagnostic on a local copy of the file rather than on a live DropBox location. I see three possibilities:
1. file can be unpacked locally by Stata; - blaime Dropbox, review your sync protocols;
2. file can be unpacked locally by some tools, but not Stata; - blame Stata, contact support;
3. file can't be unpacked locally by any tools. - blame yourself/colleagues/data source - the file is corrupt.

The message you are getting (bad compression method 9) gives some clue: Compression method 9 is DEFLATE64, which is scantly supported by open source tools. While zip64 format is supposedly valid for modern Statas (It is entirely different story if you are using an older Stata). If I am not mistaken Stata 15 and newer should be able to handle such files. Yet the commenter in the github page I refer to indicates that zlib doesn't support this method, and Stata does rely on zlib: "Stata uses portions of zlib with the express permission of the authors. See Copyright zlib for the zlib copyright notification."

Best, Sergiy