Bug report
Bug description:
When calling ZipFile.mkdir(), the user provided mode does not have the file format bits cleared, which may cause the created entry be recognized as an incorrect or unknown file format.
import io
import stat
import zipfile
with zipfile.ZipFile(io.BytesIO(), 'w') as zh:
zh.mkdir('foo/', 0o107777) # regular file
zinfo = zh.getinfo('foo/')
print(oct(stat.S_IFMT(zinfo.external_attr >> 16))) # 0o140000 (socket file)
with zipfile.ZipFile(io.BytesIO(), 'w') as zh:
zh.mkdir('foo/', 0o127777) # symbolic link
zinfo = zh.getinfo('foo/')
print(oct(stat.S_IFMT(zinfo.external_attr >> 16))) # 0o160000 (unknown)
Additionally, the current source code and doc for ZipFile.mkdir()'s default mode value are 511, which is identical to 0o777 but less intuitive.
Suggestion
Instead of the current sanitization:
zinfo.external_attr = ((0o40000 | mode) & 0xFFFF) << 16
we should probably sanitize the provided mode as what stat.S_IMODE does, i.e.:
zinfo.external_attr = (0o40000 | (mode & 0o7777)) << 16
We should probably also revise the source code and doc for ZipFile.mkdir()'s default mode value to 0o777, to be consistent with os.mkdir() and more intuitive.
CPython versions tested on:
3.14
Operating systems tested on:
No response
Linked PRs
Bug report
Bug description:
When calling
ZipFile.mkdir(), the user providedmodedoes not have the file format bits cleared, which may cause the created entry be recognized as an incorrect or unknown file format.Additionally, the current source code and doc for
ZipFile.mkdir()'s defaultmodevalue are511, which is identical to0o777but less intuitive.Suggestion
Instead of the current sanitization:
we should probably sanitize the provided mode as what
stat.S_IMODEdoes, i.e.:We should probably also revise the source code and doc for
ZipFile.mkdir()'s defaultmodevalue to0o777, to be consistent withos.mkdir()and more intuitive.CPython versions tested on:
3.14
Operating systems tested on:
No response
Linked PRs