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