GNU bug report logs - #51433
cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE

Previous Next

Full log

View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Janne Heß <janne+coreutils <at> hess.ooo>, 51433 <at> debbugs.gnu.org
Subject: bug#51433: cp 9.0 sometimes fails with SEEK_DATA/SEEK_HOLE
Date: Sat, 30 Oct 2021 11:22:13 +0100

On 30/10/2021 02:24, Paul Eggert wrote:
> On 10/28/21 12:11, Paul Eggert wrote:
>> Wait - lseek returns a number less than -1?! We could easily check for
>> that FreeBSD bug, perhaps as an independent patch; this shouldn't
>> require any extra syscalls.
> 
> I installed the attached patch to do this. This doesn't fix coreutils
> bug#51433; it merely makes 'cp' and similar programs more likely to
> detect and report the FreeBSD 9.1 bug you mentioned.

On further inspection it seems the bug is in truss :/
I.e. the only bug on FreeBSD 9.1 is that the SEEK_DATA takes ages,
but the returned values are correct.
I.e. SEEK_DATA was returning 1099511595008 in this case
which truss was reporting in 32 bit rather than 64 bit.
I see other inconsistencies in truss output,
so it can only be relied on for what syscall was called,
rather than what was passed/returned.

Given this patch doesn't change any operation,
it may be best to revert to avoid the complexity?

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.