TarFile.extractall() doesn't properly handle UNC paths

[0xd6cb6d73]

Bug report

Bug description:

TarFile.extractall() does not perform path normalization before calling os.lstat(). This is an issue on Windows as the resulting path ends us using Windows-style (\\) and unix-style (/) path separators. This results in the following error: OSError: [WinError 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\Z:\\extracted\\double-conversion-v3.1.4.tar.gz\\double-conversion-3.1.4/test/cctest'.

from Lib import tarfile


with tarfile.open(r'\\?\Z:\downloads\double-conversion-v3.1.4.tar.gz') as t:
    t.extractall(r'\\?\Z:\extracted\double-conversion-v3.1.4.tar.gz')

CPython versions tested on:

3.13, CPython main branch

Operating systems tested on:

Windows

Linked PRs

• gh-143663: Perform path normalization in TarFile.extractall() #143665

[picnixz]

I don't think we should perform normalization by ourselves. For instance _getmember() has a normalize flag but we never use it by default, only when dealing with symlinks (in _find_link_target).

As such, I think this behavior should rather be documented, though most of the APIs assume that path normalization doesn't happen unless stated otherwise.

In ZipFile there is some sanitization that is done before and there seems to be some normalization:

        # build the destination pathname, replacing
        # forward slashes to platform specific separators.
        arcname = member.filename.replace('/', os.path.sep)

        if os.path.altsep:
            arcname = arcname.replace(os.path.altsep, os.path.sep)
        # interpret absolute pathname as relative, remove drive letter or
        # UNC path, redundant separators, "." and ".." components.
        arcname = os.path.splitdrive(arcname)[1]
        invalid_path_parts = ('', os.path.curdir, os.path.pardir)
        arcname = os.path.sep.join(x for x in arcname.split(os.path.sep)
                                   if x not in invalid_path_parts)
        if os.path.sep == '\\':
            # filter illegal characters on Windows
            arcname = self._sanitize_windows_name(arcname, os.path.sep)

        if not arcname and not member.is_dir():
            raise ValueError("Empty filename.")

        targetpath = os.path.join(targetpath, arcname)
        targetpath = os.path.normpath(targetpath)

However, os.path.normpath does more than just changing separtors. It also collapses .. and changes the meaning of symlinks:

This string manipulation may change the meaning of a path that contains symbolic links.

In particular, this may not be desired. I think it's better if you already normalize the input path instead.

[picnixz]

Related/prior discussion #73974 and #57911.

[picnixz]

Also, I'm unsure whether the reason is because of UNC paths or not (does the issue also occur when you do not use r'\\?\Z:\downloads' but use paths of the form r'C:\Downloads' directly? This could also be a separate issue in tarfile itself.

[0xd6cb6d73]

I came upon this issue here: https://github.com/facebookincubator/fizz/blob/v2026.01.05.00/build/fbcode_builder/getdeps/fetcher.py#L1013. Where the following code does normalize the input path as you suggest:

if is_windows():
            # Ensure that we don't fall over when dealing with long paths
            # on windows
            src = r"\\?\%s" % os.path.normpath(self.src_dir)
else:
    src = self.src_dir

with opener(self.file_name) as t:
    # The `str` here is necessary to ensure that we don't pass a unicode
    # object down to tarfile.extractall on python2.  When extracting
    # the boost tarball it makes some assumptions and tries to convert
    # a non-ascii path to ascii and throws.
    src = str(src)
    t.extractall(src)

Where opener​ is tarfile.open​().

Looking at the error message, the part of the path that contains the unix-style separators come from the tarball's internal structure. Therefore it looks like simply normalizing the input path may not be enough.

To your second point, the issue does not manifest when the \\?\ prefix isn't used.

[picnixz]

To your second point, the issue does not manifest when the \?\ prefix isn't used.

Yeah so I think the problem is more the UNC rather than the missing normalization. I suspect that normalization wouldn't be the only way to solve this, but we could detect UNC paths like that and make this work. For instance, the culprit may be _get_filtered_attrs instead which seems to do:

    if name.startswith(('/', os.sep)):
        name = new_attrs['name'] = member.path.lstrip('/' + os.sep)

I'm not familiar enough with this part of the code and Windows though to help you so I'll ask some experts who worked on paths and tarfile filters @barneygale @encukou @jaraco (and @zooba as our Windows expert)