ADDITIONAL SYSTEM INFORMATION :
RedHat EL 9.7, GPFS 6.0.1

A DESCRIPTION OF THE PROBLEM :
Recent version of GPFS do not support copy_file_range() but rather return EOPNOTSUPP, which seems quite standard compliant.

openjdk does not handle EOPNOTSUPP when using copy_file_range().

Any application using openjdk >v17.0.x is expected to fail. pycharm 2025.x and comsol 6.4 are definitely broken do to the issue.

See for example https://github.com/golang/go/issues/41064 for a very similar issue.


REGRESSION : Last worked in version 17.0.17

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Running on a filesystem not supporting copy_file_range() (e.g. GPFS v 6.0.x):

#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#include <unistd.h>
#include <fcntl.h>

int main(int argc, const char *argv[]) {
    int in, out;
    in = open(argv[1], O_RDONLY);
    out = open(argv[2], O_CREAT | O_WRONLY, 0700);
    copy_file_range(in, 0, out, 0, 1024, 0);
    close(in);
    close(out);
    return 0;
}

will produce the error "Operation not supported". pycharm, comsol etc report the same error ...


---------- BEGIN SOURCE ----------
none
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
In src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:

< if (errno == ENOSYS)
< return IOS_UNSUPPORTED_CASE;
---
> if (errno == ENOSYS || errno == EOPNOTSUPP)
> return IOS_UNSUPPORTED_CASE;

In ./src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c
< case EXDEV:
< // ignore and try sendfile()
< break;
---
> case EXDEV:
> case EOPNOTSUPP:
> // ignore and try sendfile()
> break;

seems sufficient to fix the issue. At least replacing comsol's jre 21.0.7 by a patched jdk 21.0.10 did succeed.


FREQUENCY :
ALWAYS