Skip to content

tarfile.TarFile.add() does not normalize symlink targets on Windows #151669

Closed

Description

@dnicolodi

Bug report

Bug description:

In #138309 tarfile.TarFile.extract() has been modified to replace / in symlink targets with \ on Windows. I believe that the opposite normalization should be done in tarfile.TarFile.add().

I have noticed this in a downstream project that extracts tar archives generated by git dist, adds some additional files, and recreates the archive. When the git repository contains a symbolic link, the repacked archive contains symbolic link with the wrong path separators.

Before #138309, the extracted symbolic links on Windows were not functional (I believe) but the repacked archive had the same content as the original one. After #138309, this is not true anymore.

CPython versions tested on:

3.15

Operating systems tested on:

Windows

Linked PRs

Activity

  1. changed the title [-]`tarfile.TYarFile.add()` does not normalize symlink targets on Windows[/-] [+]`tarfile.TarFile.add()` does not normalize symlink targets on Windows[/+] on Jun 19, 2026
  2. picnixz commented on Jun 27, 2026

    @picnixz
    Member

    Considering this affects meson dist, I'm marking it as a release blocker to draw attention.

    cc @hugovk @encukou @eli-schwartz

  3. eli-schwartz commented on Jun 28, 2026

    @eli-schwartz
    Contributor

    Thanks. I'm subscribed to this ticket but most of the discussion seems to have been happening appended to #138309 (which I'm also subscribed to).

    From the meson side, I had this comment:

    If I understand correctly, using tarfile on windows to create an archive has always been wrong by default, but previously when taking a git generated tar, it was possible to roundtrip (unpack and repack) while preserving the target location set by git archive. And the roundtripping now causes a problem because unpacking will "destroy" information?

    Of course destroying information (that did not used to be destroyed) is a regression. But the discussion from the older PR has not been looking promising, unfortunately. :(

    I do hope this gets solved before final release, but a suitable fallback might, I suppose, be that meson dist can simply reject running on the combination of windows + 3.15 with an error message pointing to this ticket. I understand that that might be problematic to people whose build backend relies on a working tarfile module, but the good news is that many python developers just do releases via SaaS cloud providers (notably GitHub Actions) and aren't necessarily affected in the first place.

  4. added a commit that references this issue on Jul 10, 2026
  5. added a commit that references this issue on Jul 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    OS-windowsrelease-blockerstdlibStandard Library Python modules in the Lib/ directorytype-bugAn unexpected behavior, bug, or error

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions