GNU bug report logs -
#51857
cross-filesystem copying broken on macOS with coreutils >= 9.0
Previous Next
Full log
View this message in rfc822 format
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 <bug-coreutils <at> gnu.org> wrote:
>
> 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 <eggert <at> cs.ucla.edu> 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/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.
>>
>> Thanks, I think I see the problem now.
>>
>> Eventually macOS will likely get fixed to work around this lseek+SEEK_DATA incompatibility (as FreeBSD, Solaris, etc. all do things the Linux way and that's what I think will appear in the next POSIX), but in the meantime I attempted to work around the portability issue by installing the attached patch into Gnulib, and by syncing coreutils to the latest Gnulib.
>>
>> I don't use macOS so have not tested this. Please give it a try, either by building from bleeding-edge coreutils on Savannah, or by building from the tarball temporarily here:
>>
>> https://www.cs.ucla.edu/~eggert/coreutils-9.0.26-0f4d9.tar.gz
>>
>> Thanks.<0001-lseek-port-around-macOS-SEEK_DATA-glitch.patch>
>
>
>
>
This bug report was last modified 3 years and 241 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.