[Bug 6908] Problems with bionic libc caused by sizeof(off_t)=4 even with CONFIG_LFS=y

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=6908

--- Comment #13 from Denys Vlasenko <vda.linux at googlemail.com> 2014-02-25 21:27:12 UTC ---
(In reply to comment #12)
> So it looks like this is the problem in tar arithmetic due to this off_t/loff_t
> issue.

Other libc handle it correctly: "man fstat"

           struct stat {
...
               off_t     st_size;    /* total size, in bytes */
...
           };

See? st_size must be off_t. Bionic is doing it wrong.

> Also, it looks like Busybox tar memorizes the size in the beginning of the file
> reading, and then expects the size to be the same in the end. However, file can
> change in the middle of the process.

tar file records file size in the header.
If file shrinks mid-flight, bbox tar aborts rather than generating
invalid tar archive.

> I think the wiser approach would be if tar
> would keep reading the file as if it didn't know its size, and if the de-facto
> size (based on incomplete read call) is different, tar would issue a warning
> ("tar: The file 'filename' size has changed during archiving from the size NN1
> bytes to the size NN2 bytes").
> Assumption of the file not changing might cause some other random failures in
> tar when the file actually got truncated by the outside process.

See above.

> Also, tar opens file like this:
> open("huge3plus", O_RDONLY)             = 3
> Isn't it supposed to open it with O_LARGEFILE? In order to read arbitrary files
> one needs to always set this flag on Linux, or use open64.

That's bionic fault. On glibc, uclibc and musl, O_LARGEFILE gets passed into
open.
Bionic devels decided that 32-bits will be enough for anyone?

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.