Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've asked a few people and just thought about asking it here. We get sent files from an international company for design work in a zip format. Well when I run a script to unzip the files in the terminal, I receive a zip error only in Linux. We can test, unzip, browse, and modify the files with 7zip and winzip all day. When 7zip or Winzip is ran they do not indicate any security, too.

Terminal error:

compressed WinNT security missing (-7 bytes)

I've searched everywhere and find no solution or correction on this. One collegue suggested,

"using a different language version of Unzip could potentially change the Unicode required to extract the file. Think of it like a password, without the right code, you can't get in."

Why in the Ubuntu terminal will unzip display an error?

share|improve this question
5  
Unicode is Unicode. It doesn't just "change" because of the locale. Your colleague is wrong. –  Chris Down Dec 21 '12 at 0:10
2  
What your colleague says has a grain of truth in it (zip doesn't specify a character set for filenames, so non-ASCII filenames can become garbled when extracted on a different system), but even that grain isn't relevant to your problem. –  Ignacio Vazquez-Abrams Dec 21 '12 at 2:33
2  
7z is the name of the command once installed. See man 7z. –  jordanm Dec 21 '12 at 17:06
2  
Can you upload one of those files somewhere? –  sendmoreinfo Jan 24 '13 at 19:14
2  
It might be possible to determine more specifics if you can tell us which program (including version) the file was created by and which version of unzip you are using (try: unzip -v). –  depquid Apr 12 '13 at 13:19

1 Answer 1

I've done some digging in the source code (unzip60 from Ubuntu raring, though I suspect older versions don't differ much). The error in question is internally called TruncNTSD and defined in extract.c:295. Most uses of this message, as expected, are in win32/win32.c and indeed refer to NTFS security data, however there's only one place in the code where you should ever get this error outside of a win32 system (since you reported seeing it on ubuntu).

The place in question (extract.c:2118) is in a function called TestExtraField. As Wikipedia explains:

.ZIP file format includes the extra field facility within file headers, which can be used to store extra data not defined by existing .ZIP specifications, and allow compliant archivers not recognizing the fields to safely skip the fields.

That's indeed what NT does to store security information. Importantly, the function printing the error comments

/* we know the regular compressed file data tested out OK, or else we
 * wouldn't be here ==> print filename if any extra-field errors found
 */

So if you can unzip the files themselves fine, it looks like this error is safe to ignore. Looking further, the only place outside of win32 code that raises this error (assuming it's not a horrible bug in unzip) is test_compr_eb:extract.c:2227, which from a glance at the code looks like it occurs when a zipped file has associated extra fields that are marked as compressed, but the field data has a length of 0 bytes.

How this comes about I don't know - perhaps the program creating the zip files does this by accident, perhaps the extra fields are filtered out somewhere by security software. In any case, it looks harmless and probably has nothing to do with NT security at all. In conclusion, if your files unzip fine, it's completely safe to ignore.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.