Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/16/21 08:40, Sudhip Nashi via GNU coreutils Bug Reports wrote: It looks like this patch fixes the problem, and a quick checksum verifies this. Thanks for checking. Closing the Coreutils bug report.

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

> So, not only does macOS lseek disagree with all other implementations, it > even disagrees with the Darwin documentation. Oh wow, that’s convoluted. > To work around this macOS problem I installed the attached further patch into > Gnulib and propagated it into coreutils. Please try the lates

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/15/21 19:14, Sudhip Nashi wrote: lseek(0x3, 0x0, 0x3) = -1 Err#6 Oh my, it appears lseek (fd, 0, SEEK_HOLE) is failing with errno == ENXIO when the file has no holes, even though the Darwin man page clearly states that lseek should return the file size in that case (see

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/15/21 19:14, Sudhip Nashi wrote: lseek(0x3, 0x0, 0x3) = -1 Err#6 Oh my, it appears lseek (fd, 0, SEEK_HOLE) is failing with errno == ENXIO when the file has no holes, even though the Darwin man page clearly states that lseek should return the file size in that case (see

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

Sure, here’s the dtruss output: SYSCALL(args)= return access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2 bsdthread_register(0x1AEC802C8, 0x1AEC802BC, 0x4000) = 1073742303 0 shm_open(0x1AEB48F55, 0x0, 0xDD8000) = 3 0 fstat64(0x3, 0x16F026

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/15/21 16:02, Sudhip Nashi wrote: It doesn’t seem like this patch works. I compiled from the tarball you provided, but the destination file is still filled with NULL chars. Too bad. Can you do a dtruss or at least a ktrace/kdump for the failing program? I'd like to see what lseek is doin

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

It doesn’t seem like this patch works. I compiled from the tarball you provided, but the destination file is still filled with NULL chars. > On Nov 15, 2021, at 5:46 PM, Sudhip Nashi via GNU coreutils Bug Reports > wrote: > > Awesome, thanks for the quick response! I’ll give this a go and let y

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

Awesome, thanks for the quick response! I’ll give this a go and let you know the results. > On Nov 15, 2021, at 5:41 PM, Paul Eggert wrote: > > On 11/15/21 10:37, Sudhip Nashi wrote: >> Turns out lseek is broken (or at least works differently) on macOS as well >> (https://lists.gnu.org/archive

Re: bug#51857: cross-filesystem copying broken on macOS with coreutils >= 9.0

On 11/15/21 10:37, Sudhip Nashi wrote: Turns out lseek is broken (or at least works differently) on macOS as well (https://lists.gnu.org/archive/html/bug-gnulib/2018-09/msg00054.html). Funny coincidence! I’ll take a better look later this week if I can and try to see what the exact problem is.