8375294: (fs) Files.copy can fail with EOPNOTSUPP when copy_file_range not supported

[judovana]

Hi all,

This pull request contains a backport of commit 30cda000 from the openjdk/jdk repository.

The commit being backported was authored by Brian Burkhalter on 15 Jan 2026 and was reviewed by Alan Bateman and Jaikiran Pai.

Thanks!

This backport was clean, except of the copyright header.
Compared to clean backport to jdk25 and 26, jdk21 is missng

• JDK-8336966: Alpine Linux x86_64 compilation error: sendfile64
• trivial, applicable
• https://git.openjdk.org/jdk/commit/db168d9e10c4a302b743ee208e24ba7303fec582
• JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
  • bigger, but should be ok
  • https://git.openjdk.org/jdk/commit/fb4610e6b7a339d0a95a99d6e113e3ddda291561
• JDK-8324539: Do not use LFS64 symbols in JDK libs
• pretty big
• https://git.openjdk.org/jdk/commit/e5cb78cc88761cd27964e9fe77fc9c6f9073e888

As per myself, they are not necessary for this PR to do what it should. If you want any of them to go with/before/after, let me know

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8375294 needs maintainer approval

Error

 ⚠️ Pull request body is missing required line: - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).

Issue

• JDK-8375294: (fs) Files.copy can fail with EOPNOTSUPP when copy_file_range not supported (Bug - P4 - Requested)

Reviewers

• Andrew John Hughes (@gnu-andrew - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk21u-dev.git pull/2801/head:pull/2801
$ git checkout pull/2801

Update a local copy of the PR:
$ git checkout pull/2801
$ git pull https://git.openjdk.org/jdk21u-dev.git pull/2801/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2801

View PR using the GUI difftool:
$ git pr show -t 2801

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk21u-dev/pull/2801.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jvanek! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[openjdk]

⚠️ @judovana This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[mlbridge]

Webrevs

• 01: Full - Incremental (cb055aa0)
• 00: Full (72acb3fe)

[judovana]

/approval request Hard to reproduce issue happening after upgrading to jdk 21 from jdk17 in OpenShift with CNSA persistent storage when accessing data stored on GPFS was tracked to the backported patch

[openjdk]

@judovana
8375294: The approval request has been created successfully.

[judovana]

Hi all,

This pull request contains a backport of commit 30cda000 from the openjdk/jdk repository.

The commit being backported was authored by Brian Burkhalter on 15 Jan 2026 and was reviewed by Alan Bateman and Jaikiran Pai.

Thanks!

This backport was clean, except of the copyright header. Compared to clean backport to jdk25 and 26, jdk21 is missng

• JDK-8336966: Alpine Linux x86_64 compilation error: sendfile64
  • trivial, applicable
  • https://git.openjdk.org/jdk/commit/db168d9e10c4a302b743ee208e24ba7303fec582
• JDK-8327444: simplify RESTARTABLE macro usage in JDK codebase
  * bigger, but should be ok
  * https://git.openjdk.org/jdk/commit/fb4610e6b7a339d0a95a99d6e113e3ddda291561
• JDK-8324539: Do not use LFS64 symbols in JDK libs
  • pretty big
  • https://git.openjdk.org/jdk/commit/e5cb78cc88761cd27964e9fe77fc9c6f9073e888

As per myself, they are not necessary for this PR to do what it should. If you want any of them to go with/before/after, let me know

I was able to get it tested in reproducing environment, and it fixed the issue without any other backports.

[gnu-andrew]

/reviewers 1 reviewer

[openjdk]

@gnu-andrew
Warning: By issuing the /reviewers command in this clean backport pull request, the reviewers check has now been enabled.
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 1 (with at least 1 Reviewer).

[gnu-andrew]

This is a regression caused by JDK-8264744 which caused Linux platforms to try copy_file_range first. The effect of this patch is to cause it to return IOS_UNSUPPORTED_CASE from transferFrom0 and to try sendfile64 in the transferTo0 case i.e. what it was doing in 17u and earlier by default. At present, both fail with an IOException. It already uses sendfile64 in the case of EINVAL, ENOSYS and EXDEV so this is just handling an additional error code thrown by some calls.

Backport is clean bar copyright headers and change seems low risk. sendfile64 will be tried in some additional cases, but this was already the case for those back in 17u.

[gnu-andrew]

I'm not sure where you get this list of other changes from - just those that have changed the copyright header? - but they are not necessary for this change.

[judovana]

I'm not sure where you get this list of other changes from - just those that have changed the copyright header? - but they are not necessary for this change.

Yes, the only manual touch was the copyright header. But when I was setting that, I was curious why. The three enumerated changes are touching the the files. If the surrounding of the patch would be more +-3, it would not be clean, so I considered as worthy to mention. Sorry for confusion.