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-coreut...@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 <egg...@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>
>
>
>
>
