tarfile extraction filters raise raw ValueError for Windows drive-relative paths

[zainnadeem786]

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

Linked PRs

• gh-154987: Handle ValueError for drive-relative paths in tarfile filters #154993

[zainnadeem786]

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]

I think we already have an existing issue for that. Can you check first please?

[zainnadeem786]

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]

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]

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.