Hi Eric,
You said:
> Among other things, I can see the following changes that coreutils
> will need to make to become compliant, or else we need to push back on
> the POSIX folks if we have strong reasons to complain that their
> specification will break things:
>
> POSIX wants 'readlink non-syml
Sam James writes:
> if that is ever useful. The changes themselves look good. Really, c_f_r
> has been an API plagued with problems :(
To be fair this is not the fault of copy_file_range itself. Not that it
makes the situation any better. :)
Collin
Paul Eggert writes:
> On 2025-08-02 01:32, Pádraig Brady wrote:
>
>> it's worth mentioning run-time vs build-time checks.
>
> Yes, and this could be documented more. I installed the attached.
>
>> For reference I made some notes on various version compat at:
>> http://pixelbeat/programming/linux
On 2025-08-02 01:32, Pádraig Brady wrote:
it's worth mentioning run-time vs build-time checks.
Yes, and this could be documented more. I installed the attached.
For reference I made some notes on various version compat at:
http://pixelbeat/programming/linux_binary_compatibility.html
I need
On 02/08/2025 10:43, Martin D Kealey wrote:
On Thu, 31 Jul 2025 at 07:51, Pádraig Brady wrote:
For consistency it probably makes sense for `chmod -h` to also
not follow a symlink given as --reference=.
I know mode bits are less supported on symlinks on various systems,
but for consistency it p
On Thu, 31 Jul 2025 at 07:51, Pádraig Brady wrote:
> For consistency it probably makes sense for `chmod -h` to also
> not follow a symlink given as --reference=.
> I know mode bits are less supported on symlinks on various systems,
> but for consistency it probably makes sense.
>
[and I wrote]
>
On 02/08/2025 05:39, Collin Funk wrote:
Bruno Haible writes:
+ /* Work around glibc bug 33245
It would be good to document the workaround in
doc/glibc-functions/copy_file_range.texi.
Yep, I noticed as well. Just wanted to make sure I wasn't
misunderstanding the versions before doing i
