Description: |
Some ZIP-files generated on Windows cannot be properly extracted: the extracted files end up with a permission of `0o000`
One such ZIP-file can be downloaded via https://github.com/user-attachments/files/19111907/iem_vanilla.zip
`zipinfo -v` tells me something like this:
```
Central directory entry #1:
---------------------------
iem_vanilla/0.INTRO.txt
offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: MS-DOS, OS/2 or NT FAT
version of encoding software: 2.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2020 Oct 30 15:42:26
32-bit CRC value (hex): bda8cbfe
compressed size: 1861 bytes
uncompressed size: 4899 bytes
length of filename: 23 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: text
non-MSDOS external file attributes: 000000 hex
MS-DOS file attributes (20 hex): arc
There is no file comment.
```
The problem is apparently, that the `efattr` field for the file is something like `32`, which tcllib takes as an invitation to change the permissions, but then calculates the permissions as `0`.
Cf this code for [::zipfile::decode::CopyFile](https://core.tcl-lang.org/tcllib/file?ci=tip&name=modules/zip/decode.tcl&ln=220-234):
```
if {
($::tcl_platform(platform) ne "windows") &&
($fd(efattr) != 0)
} {
file attributes $dst -permissions \
[string map {0 --- 1 --x 2 -w- 3 -wx 4 r-- 5 r-x 6 rw- 7 rwx} \
[format %03o [expr {($fd(efattr) >> 16) & 0x1ff}]]]
}
```
(obviously, `(32>>16)&0x1ff` evaluates to `0`.
|