copy_file_range is not supported on eCryptfs

[qm3ster]

What version of Bun is running?

1.1.27+267afa293

What platform is your computer?

Linux 6.8.0-44-generic x86_64 x86_64

What steps can reproduce the bug?

I was on a machine upgraded from Ubuntu 20.04 today, and the user's home was encrypted with ecryptfs.
This causes the Bun.write copy_file_range syscall to fail with EINVAL.
Perhaps it would not be too awful to attempt a slower fallback in this situation.

What is the expected behavior?

No response

What do you see instead?

No response

Additional information

No response

[qm3ster]

In the meantime, those suffering can set the BUN_CONFIG_DISABLE_COPY_FILE_RANGE env var

[Jarred-Sumner]

Sorry about this. We currently expect copy_file_range to report that it is unsupported via EOPNOTSUP or ENOSYS, but not EINVAL. So that's interesting.

[qm3ster]

The weirdest thing for me was that when it was nksaraf/vinxi#372, the file stayed empty, while when I was manually doing either something like

const a = Bun.file('.gitignore')
const b = Bun.file('out')
await Bun.write(b, a)

or

const a = Bun.file('.gitignore')
await Bun.write('out', a)

in bun repl
some(all?) of the content was copied (but an EINVAL was still returned and repl exited because it was awaited).

If there is anything you want me to try running on this setup, let me know.