Re: sparse file check failed

[Jim Meyering]

"John T. Rose" <address@hidden> wrote:
>   In message <address@hidden>,
>   Jim Meyering writes:
>   > "John T. Rose" <address@hidden> wrote:
>   > ...
>   > > _llseek(4, 4096, [131072], SEEK_CUR)    = 0
>   > > read(3, "\0", 4096)                     = 1
>   > > _llseek(4, 1, [131073], SEEK_CUR)       = 0
>   > > read(3, "", 4096)                       = 0
>   > > ftruncate64(4, 13834516064769277953)    = -1 EINVAL (Invalid argument)
>   > > write(2, "../src/cp: ", 11)             = 11
>   > > write(2, "writing `copy\'", 14)         = 14
>   > > write(2, ": Invalid argument", 18)      = 18
>   > > write(2, "\n", 1)                       = 1
>   > >
>   > > hrm, crazy offset to ftruncate64?!
>   >
>   > Yep.  If you look at the hexadecimal representations of
>   > the two values, 13834516064769277953 and 131073:
>   >
>   >   bffe131000020001
>   >              20001
>   >
>   > you see that the bigger off_t value actually used in the
>   > ftruncate64 call actually contains the desired value
>   > in its low-order bits.  The question is what corrupted
>   > (or failed to initialize) the upper half.
>   >
>   > You might want to use a debugger to see if the
>   > variable, n_read_total, actually has the bogus value,
>   > or if the problem is in the ftruncate64 syscall.
>
> I don't have access to a working debugger on this system but I
> can report that changing n_read from ssize_t to off_t seems to
> fix the problem. Simply casting n_read to off_t when it is added
> to n_read_total fails. Maybe that will be a useful clue to you?!

Thanks.  That makes me suspicious of your compiler.
What compiler/version/options are you using?
Have you tried with and without optimization?
Can you compile with a different compiler?