Re: tar does not support partial reads

[Christian Schoenebeck]

On Dienstag, 20. Juli 2021 08:27:45 CEST Petr Pisar wrote:
> V Mon, Jul 19, 2021 at 03:39:53PM -0500, Paul Eggert napsal(a):
> > On 7/19/21 7:54 AM, Christian Schoenebeck wrote:
> > > POSIX compliant applications must always expect that read() /
> > > write() functions might read/write less bytes than requested
> > 
> > Although that's true in general, it's not true for regular files. The
> > POSIX spec for 'read'
> > <https://pubs.opengroup.org/onlinepubs/9699919799/functions/pread.html>
> > says, "The value returned may be less than /nbyte/ if the number of
> > bytes left in the file is less than /nbyte/, if the /read/() request was
> > interrupted by a signal, or if the file is a pipe or FIFO or special
> > file and has fewer than /nbyte/ bytes immediately available for reading."
> > 
> > So, regular files shouldn't get short reads unless there's an EOF or a
> > signal.
> 
> What does gaurantee there is no signal sent to the process?
> 
> -- Petr

Well, that's one point, but I cannot deny that Paul has a valid argument there 
as well. 

However it is common practice to make applications capable to deal with short 
reads independent of any prerequisites like specific file types. And like I 
said in my previous email, as far as the Linux kernel is concerned, it clearly 
sais that applications must be capable of short reads at any time and 
independent of a specific file type. BSD is yet a another story though.

And BTW it is actually not QEMU responsible for this particular behaviour, but 
rather the stock Linux kernel's 9p client that exposes this behaviour to 
applications: https://github.com/torvalds/linux/tree/master/fs/9p

Independent of 9p, you may encounter short reads with network mounted file 
systems in general as well.

The rationale behind this exposed behaviour is to allow each application to 
decide whether they want to consume the partial data currently available and 
(potentially) reduce the app's overall execution time, or rather to wait for 
the full amount of data to become available by calling read() again.

Was there a specific reason in the past for tar to switch from gnulib's 
(short-read capable) full_read() to safe_read() in 1999?

Best regards,
Christian Schoenebeck