`zipfile`: file type issues
未關閉
還沒有人認領這個 Issue。
stdlib
type-bug
- 主要語言
- Python
- 星號
- 77.2k
- 分支
- 36k
- 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 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 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
- 預估耗時
- 一週以上
- 活躍度
- 停滯
- 描述清晰度
- 需要釐清
- 新手友好度
- 25/100