Repository navigation
tarfile extraction filters raise raw ValueError for Windows drive-relative paths #154987
Description
Bug report
Bug description:
tarfile extraction filters raise a raw ValueError on Windows when handling drive-relative member names or link targets such as C:bad.txt.
This looks like an inconsistency in the extraction-filter error handling path. The affected cases are rejected through a raw ValueError from Windows path handling instead of the structured tarfile filter exceptions that similar rejected paths use.
For example, with filter="data" and errorlevel = 0, I expected the invalid member to be skipped/refused and extraction to continue to later members. Instead, extraction aborts with:
ValueError: Paths don't have the same drive
Minimal reproducer:
import io
import os
import tarfile
import tempfile
from pathlib import Path
def add_file(tf, name, data=b"x"):
info = tarfile.TarInfo(name)
info.size = len(data)
tf.addfile(info, io.BytesIO(data))
def build_archive_with_drive_relative_member(path):
with tarfile.open(path, "w") as tf:
add_file(tf, "before.txt", b"before")
add_file(tf, "C:bad.txt", b"bad")
add_file(tf, "after.txt", b"after")
def main():
if os.name != "nt":
print("This reproducer is Windows-specific.")
return 0
with tempfile.TemporaryDirectory() as tmp:
tmp = Path(tmp)
archive_path = tmp / "drive_relative.tar"
extract_dir = tmp / "extract"
extract_dir.mkdir()
build_archive_with_drive_relative_member(archive_path)
try:
with tarfile.open(archive_path, "r") as tf:
tf.errorlevel = 0
tf.extractall(extract_dir, filter="data")
except Exception as exc:
print("exception_type:", type(exc).__name__)
print("exception_message:", str(exc))
print("before_exists:", (extract_dir / "before.txt").exists())
print("after_exists:", (extract_dir / "after.txt").exists())
if __name__ == "__main__":
raise SystemExit(main())Observed output on Windows:
exception_type: ValueError
exception_message: Paths don't have the same drive
before_exists: True
after_exists: False
Expected behavior:
The drive-relative member should be handled through the normal tarfile extraction-filter exception path, for example OutsideDestinationError, so that errorlevel = 0 can skip/refuse that member and continue extracting later members.
Expected output would be:
before_exists: True
after_exists: True
I also observed the same raw ValueError behavior for drive-relative hardlink and symlink targets under filter="data".
Expected structured exceptions:
Drive-relative member name: OutsideDestinationError
Drive-relative hardlink target: LinkOutsideDestinationError
Drive-relative symlink target: LinkOutsideDestinationError
The issue appears to come from ntpath.commonpath() raising ValueError for incompatible drive/path semantics, and that exception escaping directly instead of being converted into the appropriate tarfile filter exception.
A possible fix would be to treat ValueError from the containment/commonpath check as an outside-destination condition and raise the appropriate structured tarfile exception.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Windows
Activity
zainnadeem786 commentedon Jul 31, 2026
I’m also working on a small fix and regression tests for the Windows-specific tarfile extraction-filter error handling inconsistency, and I’ll link the PR once it’s ready.
picnixz commentedon Jul 31, 2026
I think we already have an existing issue for that. Can you check first please?
zainnadeem786 commentedon Jul 31, 2026
Hi @picnixz
Thanks for pointing that out. I searched the existing tracker and found #133890, which discusses unexpected exceptions escaping from tarfile extraction filters, including a possible "ValueError" from filesystem path handling.
However, that issue appears to focus primarily on non-UTF-8 locale failures and "UnicodeEncodeError". This report specifically covers Windows drive-relative member names and link targets such as "C:bad.txt", where "ntpath.commonpath()" raises:
ValueError: Paths don't have the same drive
This also affects "errorlevel = 0", because the raw "ValueError" bypasses the normal "FilterError" handling and prevents extraction from continuing.
Is #133890 the existing issue you had in mind, or is there another issue specifically covering Windows drive-relative paths? I’m happy to close this issue and move the PR/tests to the existing one if it is considered a duplicate.
picnixz commentedon Jul 31, 2026
I had other issues in mind about ValueError escaping in general but I believe your issue is similar yet different so we can treat it as a new one.
zainnadeem786 commentedon Jul 31, 2026
Thanks for confirming. The fix and regression tests are already submitted in #154993, so I’ll keep the PR focused on this Windows-specific case.
encukou commentedon Oct 9, 2026
Thanks for the report!
I think the filters should treat drive-relative paths the same way as absolute paths, i.e. reject them;
data_filtershould also reject them in link targets.Do you want to make that change?