Re: git: 643336549081 - main - If copy_file_range(2) fails with EXDEV, use fall-back.
- Reply: Martin_Matuška : "Re: git: 643336549081 - main - If copy_file_range(2) fails with EXDEV, use fall-back."
- Reply: Alexey Dokuchaev : "Re: git: 643336549081 - main - If copy_file_range(2) fails with EXDEV, use fall-back."
- In reply to: Mateusz Guzik : "Re: git: 643336549081 - main - If copy_file_range(2) fails with EXDEV, use fall-back."
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 04 Apr 2023 10:31:53 UTC
Mateusz Guzik wrote: > On 4/4/23, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote: >> -------- >> Alexey Dokuchaev writes: >> >>> Okay, but did it leave an empty file, I wonder? >> >> I didn't check, but it probably would, because cp(1) must have opened >> and created the destination in order to call copy_file_range(2). >> >> PS: I'll note that EXDEV is not a documented return value from >> copy_file_range(2), and my surprise that cp(1) did not revert >> to the fall-back, no matter why copy_file_range(2) failed. >> > > that's a new one and should not be happening, something is borked in > the kernel -- cross device copies *are* supported > > i'll look into it later Likely has to do with openzfs merge issues reported by Cy just above?