`zipfile`: file type issues
オープン
まだ誰も着手していません。
stdlib
type-bug
- 主要言語
- Python
- スター
- 77.2k
- フォーク
- 35.9k
- PR マージ指標
- PR 指標を取得中
説明
Bug report
Bug description:
Hey.
I think there exist a number of issues (which may, depending on how code is used, in principle even be security relevant).
First, AFAIU, ZIP files may contain (at least) regular files, directories (as "standalone" items in the archive, like an empty directory) and symbolic links.
For example using the zip program:
$ mkdir empty
$ zip d.zip empty
adding: empty/ (stored 0%)
$ ln -s /dev/null bar
$ zip --symlinks s.zip bar
adding: bar (stored 0%)
$
When I open the one with the symlink in Python:
>>> import zipfile
>>> z = zipfile.ZipFile("s.zip", "r")
>>> z.namelist()
['bar']
>>> f = z.open("bar", "r")
>>> f.read()
b'/dev/null'
>>> i = z.getinfo("bar")
>>> i.is_dir()
False
>>> p = zipfile.Path(z, "bar")
>>> p.filename
PosixPath('s.zip/bar')
>>> p.is_dir()
False
>>> p.is_file()
True
>>> p.is_symlink()
True
>>>
- It's IMO debatable whether
z.open("<symlink>", "r")should succeed or not. IMOzipfile.ZipFile.open()quite clearly is ZIP'sopen(), but that AFAIK, never opens symlinks but only follows them. - Even if that behaviour is desired (i.e. like a
os.readlink()for ZIPs), then it's still completely unexpected and the ZipFile object has nois_symlink()-method ... (onlyzipfile.Pathhas such, so one needs to create that first, which seems quite unhandy). - Speaking of which
zipfile.Path’sis_dir(),is_file()andis_symlink()functions seem either buggy or semantically inconsistent and/or badly documented.
Usually, "file" means either any type of file (directory, symlink, device, etc.) or regular files (and sometimes also symlinks if they point to regular files).
Here, the symlink points to nothing, so it cannot be the latter case. Also - see below - a directory wouldn't returnTrueforis_file(), so the it's not the former either.
The docs also don't meantion what "file" means.
Now the same with d.zip:
>>> import zipfile
>>> z = zipfile.ZipFile("d.zip", "r")
>>> z.namelist()
['empty/']
>>> f = z.open("empty/", "r")
>>> f.read()
b''
>>> i = archive_file.getinfo("empty/")
>>> i.is_dir()
True
>>> p = zipfile.Path(z,"empty/")
>>> p.filename
PosixPath('d.zip/empty')
>>> p.is_dir()
True
>>> p.is_file()
False
>>> p.is_symlink()
False
>>>
- IMO, that
zipfile.ZipFile.open()succeeds on a directory (and gives an emptybytes) seems pretty strange at best. It does so even if the directory isn't empty but contains files. - There's also that thing that sometimes that directory pathnames are suffixed by
/and sometimes not. Maybe I've missed it but that doesn't seem to be documented, but may be crucial when e.g. matching filenames - and is IMO unexpected. - As mentioned above,
is_file()here isFalse, which would imply that the meaning of that function should be that a file is either a regular file or a regular file or a symbolic link pointing to such.
Cheers,
Chris.
CPython versions tested on:
3.13
Operating systems tested on:
Linux
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、zipfile.ZipFile.open()、ZipInfo.is_dir()、および zipfile.Path.is_dir()、is_file()、is_symlink() を使って Python 3.13 の例を再現します。関連する zipfile のドキュメントとテストを読み、完了基準を定義する前に、ディレクトリ、通常のファイル、シンボリックリンク、末尾のスラッシュについて意図されたセマンティクスを確立します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- python
- 領域
- operating-systems
- issue の種類
- バグ
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100