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
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
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
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
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
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
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.