I have a folder with subfolders and files. I create a .zip file via powershell's Compress-Archive
.
Problem is that the file structure is messed up when opened in Linux.
Bad is the bad.zip archive made in Powershell with Compress-Archive
,
and Good is good.zip made with Windows' WinRAR.
This is how it looks on Linux: (Left is bad, right is good)
File contents seen in Linux with cat
: (left is bad, right is good):
How to fix this problem??
...
I tried replacing all "\" in bad.zip with "/" in nano and it worked.
I tried automating that with this script, but unsuccessfully:
#!/bin/bash
contents=$(cat $1)
echo "${contents//\\//}"
I run the script:
./FixZip.sh bad.zip > new.zip
The backslashes have been replaced, as intended, but new.zip cannot be opened. The reason is probably the encoding is different...
This is the encoding for the zip files:
terminal:# file -i bad.zip
bad.zip: application/zip; charset=binary
terminal:# encguess bad.zip
bad.zip UTF-32LE
terminal:# file -i new.zip
new.zip: application/octet-stream; charset=binary
terminal:# encguess new.zip
new.zip unknown
terminal:# cat new.zip
P5�WMCw:a_folder/test2.txt+��IP7�WM���a_folder/test3.txt�(*P4�WM��6a_folder/subf/test1.txt�H���P5�WMCw:a_folder/test2.txtP7�WM���7a_folder/test3.txt4�WM��6ma_folder/subf/test1.txtPKũ
$(cat $1)
will replace any sequence of white-space characters by a single space; (3) back-slashes will occur in the compressed data, as well as in the file index, so replacing them will further corrupt the file. It's not obvious why thePK
magic number should have been replaced, but I would guess return, back-space or escape characters in the binary would account for it. As @KamilMaciorowski recommends,xxd
will clarify what's going on. – AFH Oct 23 '18 at 21:10PortableApps\
directory, which contains 32- and 64-bit versions of both the GUI and the7z.exe
command-line version, which I imagine will need one or more of the.dll
files. – AFH Oct 23 '18 at 22:00