Re: [Bug-tar] Tar short read

[Andreas Dilger]

On 2011-09-27, at 11:53 PM, Paul Eggert wrote:
> If I understand this patch correctly, it has an effect
> only on hosts where SSIZE_MAX < INT_MAX.  But there
> are no such hosts in practice.  So this patch addresses
> only theoretical issues, right?

There are a couple of fixes in the patch:
- The SSIZE_MAX fix pre-validates the read size and doesn't strictly
  have anything to do with INT_MAX, while the fix for Tru64 is a
  post-facto workaround.  Since SUSv2 says the behaviour for reads
  larger than SSIZE_MAX (which happens to be the same as INT_MAX on
  32-bit platforms) is undefined, it is better not to rely on read()
  returning EINVAL before switching to the smaller reads.  On 64-bit
  platforms this check never does anything, since SSIZE_MAX is 2^63.
- In case of SSIZE_MAX or BUGGY_READ_MAXIMUM, it continues to read
  into the buffer in smaller chunks until the read is completed.  It
  seems to be a bug that BUGGY_READ_MAXIMUM internally truncates the
  read but didn't read as many bytes as requested.
- This read continuation for BUGGY_READ_MAXIMUM and SSIZE_MAX also
  handles the short read() case that Kevin reported.

That said, looking more closely at the rest of the code, I see that
a function called full_rw() already exists that calls safe_rw() and
handles the case of a short read that could be used directly instead
of handling it at two levels.

It looks like changing dump_regular_file(), sparse_dump_region(), and
check_sparse_region(), check_data_region() to use full_read() instead
of safe_read() would be enough.

Cheers, Andreas