How to create a zip file compatible with Windows under Linux

Question

I need to make a zip file available to all my Windows users visitors, so I naively produced a zip file with the Unix zip command (let's call it madeinlinux.zip).

It opens successfully with WinRar or Winzip, but those of my users who are using the standard Windows zip file handling experience failure when trying to unzip it. (Windows XP)

I compressed the same data using Windows built-in zip mecanism, and from a Linux point of view, I cannot see any difference in the file type:

$ file madeinlinux.zip :  Zip archive data, at least v2.0 to extract
$ file madeinwindows.zip : Zip archive data, at least v2.0 to extract

They're must be something specific to a Windows compatible zip file.

Does anyone knows what?

Answer 1

Try with:

zip -9 -y -r -q file.zip folder/

• -9 Indicates the slowest compression speed (optimal compression, ignores the suffix list)
• -y Store symbolic links as such in the zip archive, instead of compressing and storing the file referred to by the link
• -r Travel the directory structure recursively
• -q Quiet mode

Answer 2

7zip is an open source compression tool that works on Linux, FreeBSD, Mac OS X, BeOS, DOS, Amiga and Windows.

I would highly recommend it based on the windows version.

It supports

packing / unpacking: 7z, ZIP, GZIP, BZIP2 and TAR

Unpacking only: ARJ, CAB, CHM, CPIO, DEB, DMG, HFS, ISO, LZH, LZMA, MSI, NSIS, RAR, RPM, UDF, WIM, XAR and Z.

Answer 3

zip -Z sets the compression option. -Z store is the most trivial one, as it doesn't compress at all. This is useful when you're using zip as an alternative for tar, or when troubleshooting. In this case you should try to see if an uncompressed archive is usable from Windows. If that is usable, you know that you'll have to pick a non-default compression option.

Answer 4

Only thing that looks relevant is this

-k - Attempt  to  convert  the  names  and paths to conform to MSDOS, store only the MSDOS attribute (just the user write attribute from UNIX), and mark the entry as made under
MSDOS (even though it was not); for compatibility with PKUNZIP under MSDOS which cannot handle certain names such as those with two dots.

but do read "man zip" on your system before going anywhere else...

Answer 5

In addition to what others suggested, it's important pay Attention to your file and directory names as Windows does not necessarily like Linux file path and names. It sometimes also escapes them differently when zipping. Examples are numerous, but most importantly dot files (. and ..), files with only case differences (name.txt and NAME.txt), absolute file paths (/tmp/file.txt). Some other characters which are allowed in file names on Windows could cause issues when Windows Explorer is used to open files. In my case ':' character was the deal breaker but took a lot of work to find this out.

So before you resume to using using a lot of parameters, I suggest follow a simple procedure:

1. Locate the folder or file your zipping up.

2. run: zip -9 -r -k zip-modified-names.zip /path/to/your/folder

3. pay attention to what the console spits out. In my case ':' in file names were stripped out.
4. Move the zip file to a windows machine and attempt to open it.

If this works, you may be better off removing the characters that have been stripped off by -k option from your file/directory names try zipping normally. Note some parameters such as -k have side effects. In this case -k contradicts with -q option (for sym links).

Also -k option may render your file names unreadable. In my case my files were named based on creation time (e.g. 10:55:39.pdf) to facilitate easily locating the required record from archives, but -k option turned it to 105539.pdf which is not easily readable by users. I hence changed the names to 10_55_39.pdf which opens on Windows without using -k option but is still readable.

Answer 6

Had a similar issue recently with files produced from a perl script. Found that native windows zip (tested Windows 7 only) incorrectly handles paths with a leading slash and displays an empty zipfile. Solution was to strip the leading slash before adding files. Perhaps some versions of the linux zip command store file paths with leading slashes.

Answer 7

Here is a python script that I am using to zip some files. It has been tested on ubuntu and Vista. A zip generated on Ubuntu opens with the Vista zipper.

I think that I had a similar issue in the past and it was because the zip format was not ZIP_DEFLATED. I am not sure. I will check that.

I hope it helps

import zipfile
import glob, os, sys

class ZipArchive:

    def zip_it(self, dirName, files):
        dirNamePrefix = dirName+"/*"
        for filename in glob.glob(dirNamePrefix):
            if os.path.isfile(filename) and (not self.exclude_svn or (filename.find(".svn\\")==-1)):
                print filename
                name = filename[len(self.folder)+1:]
                self.archive.write(filename, name, zipfile.ZIP_DEFLATED)

    def run(self, folder, name, exclude_svn):
        self.exclude_svn = exclude_svn
        self.folder = folder
        self.archive = zipfile.ZipFile(name+".zip", "w")
        os.path.walk(self.folder, ZipArchive.zip_it, self)
        self.archive.close()

if __name__ == "__main__":
    if (len(sys.argv)==1):
        print "usage zipit folder [name] [svn:yes|no]"
    else:
        name = sys.argv[1]
        exclude_svn = False

        if (len(sys.argv)>2): name = sys.argv[2]
        if (len(sys.argv)>3): exclude_svn = (sys.argv[3]=="no")

        arch = ZipArchive()
        arch.run(sys.argv[1], name, exclude_svn)
        print "done"

Answer 8

There is probably a problem in your file transference from Linux to Windows. If you´re using FTP, try setting a binary transfer (bin command in Windows, before the transference of your files from Linux to Windows).

Answer 9

Xubuntu22.04 zipping for Windows10:

I was not able to create a zip-file with either "Engrampa" nor "Archive Manager" for windows10 users.

But with the command line command

zip -r archive.zip sources

I can zip with linux and extract this with windows10 explorer.