Closed sunclx closed 9 months ago
Unfortunately, I have absolutely no idea of what the "header identification information" is. When I run 7z t
with a zip file generated with this demo, everything looks fine.
7z t test-integ.zip
7-Zip [64] 17.05 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28
p7zip Version 17.05 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,8 CPUs LE)
Scanning the drive for archives:
1 file, 4143058 bytes (4046 KiB)
Testing archive: test-integ.zip
--
Path = test-integ.zip
Type = zip
Physical Size = 4143058
Everything is Ok
Files: 4
Size: 6384084
Compressed: 4143058
I unzip the zip file and open with visual studio code. It display that the files end with lots of null.
How did you create your zip file? This is not normal.
By cli-deno
command.
I cannot reproduce the issue. On my end, the cli-deno
demo always generate a zip file that does not end with NUL characters. I use https://hexed.it/ to check the content.
deno --version
deno 1.37.1 (release, x86_64-pc-windows-msvc) v8 11.8.172.6 typescript 5.2.2
command:
deno run -A clie-deno/mc-zip.js out.zip C:\dev\scripts
I'm still unable to reproduce the issue when I run deno run mc-zip.js test.zip ..\
from the cli-deno
folder on Windows 11. The zip file is weighting 30 459 859
bytes and is valid.
deno --version
deno 1.37.1 (release, x86_64-pc-windows-msvc)
v8 11.8.172.6
typescript 5.2.2
I try in anthor PC, and the issue happend again. I run deno run mc-zip.js test.zip ..\
from the cli-deno
folder on Windows 11. When I unzip the test.zip
file, I find that the files size is differnet from original and the size is multiples of 64k.
When I set the option useWebWorkers
to false
, the issue disappears. Maybe there is a bug in Deno Web Workers.
That's weird because I did several tests and I cannot reproduce the issue at all on Windows.
When I open the zip file producted by![](https://github.com/sunclx/pics/blob/main/2023-10-06%20161559.png?raw=true)
zip.js
with bandzip, it report error "The extracted file size and the archive header information are different".