Re: sparse file check failed

[Jim Meyering]

"John T. Rose" <address@hidden> wrote:
...
> # ../src/dd bs=1 seek=131073 of=sparse < /dev/null
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 0.726926 s, 0.0 kB/s
> # ll
> total 0
> -rw-r--r-- 1 root root 131073 Dec  6 09:41 sparse
> # du -sh *
> 0       sparse
> # strace -o tr ../src/cp --sparse=always sparse copy
> ../src/cp: writing `copy': Invalid argument
> # ll
> total 12
> -rw-r--r-- 1 root root      0 Dec  6 09:43 copy
> -rw-r--r-- 1 root root 131073 Dec  6 09:41 sparse
> -rw-r--r-- 1 root root   8207 Dec  6 09:43 tr
>
> Here is the tail part of the trace ...
...
> _llseek(4, 4096, [126976], SEEK_CUR)    = 0
> read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 
> 4096
> _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.