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.

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

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

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

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

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

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

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

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.

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

On 11/15/21 15:20, Pádraig Brady wrote: I also have access to a macOS system, so I'll also test out if there are ways to use SEEK_DATA there. Could you try the latest savannah Git instead? I installed something into Gnulib that I hope lets coreutils use SEEK_DATA on macOS as before. The Gnuli

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

On 15/11/2021 18:37, Sudhip Nashi via GNU coreutils Bug Reports wrote: On Nov 15, 2021, at 11:33, Paul Eggert wrote: Is the source file on a ZFS file system by any chance? See my lseek comment below. On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote: stat64("/tmp/test\

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

On Mon, Nov 15, 2021 at 01:33:44PM -0800, Paul Eggert wrote: > On 11/15/21 09:40, Cameron Katri wrote: > > Did you build vanilla coreutils 9.0 yourself? If so, what commands did you > you use to build it, exactly? If not, who built coreutils and how did they > configure and/or modify it? I worry t

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

On 11/15/21 09:40, Cameron Katri wrote: No, this is one APFS (Apple File System). OK, so ZFS is not involved. unlink("/private/tmp/test\0", 0x0, 0x0)= 0 0 What's causing this use of "/private/tmp"? I don't see that in the GNU cp source code. Can you put a breakpoint on clo

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

> On Nov 15, 2021, at 11:33, Paul Eggert wrote: > > Is the source file on a ZFS file system by any chance? See my lseek comment > below. > >> On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote: >> >> stat64("/tmp/test\0", 0x16DDC36C0, 0x0) = 0 0 >> fstatat64(0x

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

On Mon, Nov 15, 2021 at 09:33:21AM -0800, Paul Eggert wrote: > Is the source file on a ZFS file system by any chance? See my lseek comment > below. No, this is one APFS (Apple File System). > > On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote: > > > stat64("/tmp/test\0", 0x1

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

Is the source file on a ZFS file system by any chance? See my lseek comment below. On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote: stat64("/tmp/test\0", 0x16DDC36C0, 0x0)= 0 0 fstatat64(0xFFFE, 0x16DDC3C21, 0x16DDC2BA0) = 0 0 fstatat64

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

> On Nov 15, 2021, at 10:09 AM, Pádraig Brady wrote: > > On 15/11/2021 04:02, Sudhip Nashi via GNU coreutils Bug Reports wrote: >> Hello, >> Cross-filesystem copying seems to have been broken in the latest coreutils >> release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ >>

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

On 15/11/2021 04:02, Sudhip Nashi via GNU coreutils Bug Reports wrote: Hello, Cross-filesystem copying seems to have been broken in the latest coreutils release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ appears to return successfully, but if one analyzes /tmp/test, it’s fi

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

Hello, Cross-filesystem copying seems to have been broken in the latest coreutils release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ appears to return successfully, but if one analyzes /tmp/test, it’s filled with NULL characters. However, copying works fine when the source a