fix(install): follow Windows runfiles junctions when copying files by JSGette · Pull Request #1076 · bazelbuild/rules_pkg

JSGette · 2026-08-13T11:52:02Z

pkg_install fails on Windows when --enable_runfiles is set. Bazel materializes file runfiles as directory junctions, but junctions cannot point at files, so shutil.copyfile or open() raises PermissionError: [Errno 13] Permission denied.

os.path.realpath() resolves full path following symlinks, so that is essentially a no-op on Unix (extra stat() call) but resolves junctions on Windows

### What does this PR do? As described in bazelbuild/rules_pkg#1076, Bazel creates a junction on files that is wrong as they are only supposed to be used with directories. This leads to permission errors: ```python PermissionError: [Errno 13] Permission denied ``` Co-authored-by: joseph.gette <joseph.gette@datadoghq.com>

aiuto · 2026-09-30T04:43:07Z

Can you rebase and push so tests run without the broken setup.

--enable_runfiles on Windows creates directory junctions for file runfiles. Junctions cannot point at files, so shutil.copyfile fails with Permission denied. Resolve the reparse point before copying.

@alopezz

Suggested by @alopezz: realpath resolves reparse points on Windows and symlinks on Unix, removing the need for sys.platform conditional and os.readlink try/except.

Since rules_python 1.9, py_binary/py_test default to --enable_runfiles on Windows. Bazel may then create a directory junction for a file runfile, which cannot be opened or executed ("Permission denied"). Raising the minimum rules_python to 2.3.0 exposed this in our Windows tests and in verify_archive_test. Resolve runfiles paths with os.path.realpath before opening them, as was done for pkg_install in bazelbuild#1076.

Since rules_python 1.9, py_binary/py_test default to --enable_runfiles on Windows. Bazel may then create a directory junction for a file runfile, which can not be opened or executed ("Permission denied"). Raising the minimum rules_python to 2.3.0 exposed this in our Windows tests and in verify_archive_test. os.path.realpath does not help: on Windows it fails on such a junction with WinError 267. Read the junction target with os.readlink instead, in verify_archive_test, in pkg_install (replacing the realpath from bazelbuild#1076) and, through //tests/util:runfiles_util, in the tests.

### What does this PR do? Bump `rules_pkg` to 1.3.0 and repin its `archive_override` to upstream main at bazelbuild/rules_pkg#1076, which upstreams the local Windows junction patch. Apply the pending bazelbuild/rules_pkg#1084 on top as the only patch. ### Motivation RPM 4.20 redefined `%{_builddir}` as a per-package build directory (rpm-software-management/rpm#2885), which breaks the relative paths `rules_pkg` generates for `%install` and `%files`. With RPM 6.0.1, as shipped by Ubuntu 26.04 LTS, `bazel build //packages/dogstatsd:rpm` fails with `Could not open %files file` and `//packages/installer/linux:rpm` with `cp: cannot stat ...README_rpm.md`. CI images ship RPM 4.18.2 and older, so they are not affected yet, but running them against the patch proves it keeps working with older RPM versions, which upstream cannot test. ### Describe how you validated your changes Both targets above build with RPM 6.0.1, whereas they fail without this change once `MakeRpm` actions bypass caches (`--modify_execution_info=MakeRpm=+no-cache`). ### Additional Notes `rpmbuild` is a system toolchain absent from action keys, so cached RPMs mask both the breakage and the fix.

### What does this PR do? Bump `rules_pkg` to 1.3.0 and repin its `archive_override` to upstream main at bazelbuild/rules_pkg#1076, which upstreams the local Windows junction patch. Apply the pending bazelbuild/rules_pkg#1084 on top as the only patch. ### Motivation RPM 4.20 redefined `%{_builddir}` as a per-package build directory (rpm-software-management/rpm#2885), which breaks the relative paths `rules_pkg` generates for `%install` and `%files`. With RPM 6.0.1, as shipped by Ubuntu 26.04 LTS, `bazel build //packages/dogstatsd:rpm` fails with `Could not open %files file` and `//packages/installer/linux:rpm` with `cp: cannot stat ...README_rpm.md`. CI images ship RPM 4.18.2 and older, so they are not affected yet, but running them against the patch proves it keeps working with older RPM versions, which upstream cannot test. ### Describe how you validated your changes Both targets above build with RPM 6.0.1, whereas they fail without this change once `MakeRpm` actions bypass caches (`--modify_execution_info=MakeRpm=+no-cache`). ### Additional Notes The `rpmbuild` version only reaches `MakeRpm` action keys through `--debuginfo_type`, which no target enables, so cached RPMs mask both the breakage and the fix.

…57825) ### What does this PR do? Bump `rules_pkg` to 1.3.0 and repin its `archive_override` to upstream main at bazelbuild/rules_pkg#1076, which upstreams the local Windows junction patch. Conversely, apply the pending bazelbuild/rules_pkg#1084 on top as the only patch. ### Motivation RPM 4.20 redefined `%{_builddir}` as a per-package build directory (rpm-software-management/rpm#2885), which breaks the relative paths `rules_pkg` generates for `%install` and `%files`. With RPM 6.0.1, as shipped by Ubuntu 26.04 LTS (author's laptop), `bazel build //packages/dogstatsd:rpm` fails with `Could not open %files file` and `//packages/installer/linux:rpm` with `cp: cannot stat ...README_rpm.md`. CI images ship RPM 4.18.2 and older, so they are not affected yet, but running them against the patch proves it keeps working with older RPM versions, which upstream doesn't necessarily cover. ### Describe how you validated your changes Both targets above build with RPM 6.0.1, whereas they fail without this change once `MakeRpm` actions bypass caches (`--modify_execution_info=MakeRpm=+no-cache`). ### Additional Notes The `rpmbuild` version only reaches `MakeRpm` action keys through `--debuginfo_type`, which no target enables, so cached RPMs might mask both the breakage and the fix when switching the base build image to Ubuntu 26.04. This dormant issue predates bazelbuild/rules_pkg#1084, and therefore deserves a separate upstream contribution. Co-authored-by: regis.desgroppes <regis.desgroppes@datadoghq.com>

### What does this PR do? Enables symlinks for Bazel on Windows, using the [`--windows_enable_symlinks`](https://bazel.build/reference/command-line-reference#param-no-windows-enable-symlinks) flag. This causes symlinks to be used for files on Windows (directories still use junctions), instead of dynamically choosing between a copy or a junction (as per [this chunk of Bazel code](https://github.com/bazelbuild/bazel/blob/e89755babf3e941bc1e9d8120b1cd48854ab9dfa/src/main/java/com/google/devtools/build/lib/windows/WindowsFileSystem.java#L88-L99)). This [requires Developer mode](https://bazel.build/configure/windows#symlink), but that's already something we assume, given that we're already setting `--enable_runfiles`, which has the same requirement. ### Motivation Trying to enable certain tests on Windows (e.g. #58039), we hit errors such as [this](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/2132479975/viewer#L978): `The directory name is invalid`. This error happens because of files under runfiles being represented by junctions in certain circumstances (see bazelbuild/rules_pkg#1076 for a workaround for such an instance). As can be seen from the Bazel logic linked above, without symlinks enabled, Bazel makes a best effort based on what it knows: if the target of the link exists, it will copy the file; otherwise, it creates a junction to represent the file. However, Windows junctions are reparse points that can only point at directories, and therefore the OS throws an error when attempting to read them as if they were files. The fact that this depends on whether the target of the link exists (the target may not exist at runfile creation time depending on what Bazel can assume already exists in the remote / disk cache), the behavior is not predictable. This explains why those failures are inconsistent. Rather than accounting for this on code that uses runfiles, it seems preferable to enable symlinks and get behavior that is more consistent with what we see on other OSes. ### Describe how you validated your changes Passing CI. Also tested on a branch where the motivation error was present ([here](https://gitlab.ddbuild.io/DataDog/datadog-agent/-/jobs/2136753160)). ### Additional Notes Co-authored-by: alex.lopez <alex.lopez@datadoghq.com>

JSGette mentioned this pull request Aug 14, 2026

Copy python files to avoid junction issues DataDog/datadog-agent#54819

Merged

tonyaiuto approved these changes Sep 30, 2026

View reviewed changes

JSGette added 2 commits October 1, 2026 10:04

fix(install): follow Windows runfiles junctions when copying files

cf636c7

--enable_runfiles on Windows creates directory junctions for file runfiles. Junctions cannot point at files, so shutil.copyfile fails with Permission denied. Resolve the reparse point before copying.

Use os.path.realpath instead of platform-specific junction resolution

e5e3b7c

Suggested by @alopezz: realpath resolves reparse points on Windows and symlinks on Unix, removing the need for sys.platform conditional and os.readlink try/except.

JSGette force-pushed the jsgette/pkg-install-windows-junctions branch from 2bd3f8c to e5e3b7c Compare October 1, 2026 08:04

JSGette marked this pull request as ready for review October 1, 2026 08:05

JSGette requested review from aiuto and cgrindel as code owners October 1, 2026 08:05

aiuto merged commit 1b2295d into bazelbuild:main Oct 1, 2026
6 checks passed

onnosteenbergen-samotics mentioned this pull request Oct 7, 2026

Use explicit __init__.py files instead of implicit creation #1082

Open

rdesgroppes mentioned this pull request Oct 8, 2026

Trade an upstreamed rules_pkg patch for rpmbuild 4.20+ support DataDog/datadog-agent#57825

Merged

alopezz mentioned this pull request Oct 14, 2026

Enable symlinks for Bazel on windows DataDog/datadog-agent#58118

Merged

Navigation Menu

Repository navigation

fix(install): follow Windows runfiles junctions when copying files - #1076

fix(install): follow Windows runfiles junctions when copying files#1076
aiuto merged 2 commits into
bazelbuild:mainfrom
JSGette:jsgette/pkg-install-windows-junctions

JSGette commented Aug 13, 2026 •

edited

Loading

Uh oh!

aiuto commented Sep 30, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

JSGette commented Aug 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aiuto commented Sep 30, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

JSGette commented Aug 13, 2026 •

edited

Loading