tags 630029 fixed-upstream
thanks
And here's the documentation fix.
Thanks,
Michael
diff --git a/man2/pread.2 b/man2/pread.2
index de1e951..c7a7fdd 100644
--- a/man2/pread.2
+++ b/man2/pread.2
@@ -85,6 +85,12 @@ and
.BR pwrite ()
returns the number of bytes written.
+Note that is not an error for a successful call to transfer fewer bytes
+than requested (see
+.BR read (2)
+and
+.BR write (2)).
+
On error, \-1 is returned and
.I errno
is set to indicate the cause of the error.
diff --git a/man2/read.2 b/man2/read.2
index 62d7d8b..c581f72 100644
--- a/man2/read.2
+++ b/man2/read.2
@@ -87,6 +87,8 @@ available right now (maybe because we were close to
end-of-file, or
because we are reading from a pipe, or from a terminal), or because
.BR read ()
was interrupted by a signal.
+See also NOTES.
+
On error, \-1 is returned, and
.I errno
is set appropriately.
@@ -178,6 +180,14 @@ or to return the number of bytes already read.
.SH CONFORMING TO
SVr4, 4.3BSD, POSIX.1-2001.
.SH NOTES
+On Linux,
+.BR read ()
+(and similar system calls) will transfer at most
+0x7ffff000 (2,147,479,552) bytes,
+returning the number of bytes actually transferred.
+.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69
+(This is true on both 32-bit and 64-bit systems.)
+
On NFS filesystems, reading small amounts of data will update the
timestamp only the first time, subsequent calls may not do so.
This is caused
diff --git a/man2/readv.2 b/man2/readv.2
index 3cc0813..3cf0c2f 100644
--- a/man2/readv.2
+++ b/man2/readv.2
@@ -184,6 +184,13 @@ return the number of bytes read;
and
.BR pwritev ()
return the number of bytes written.
+
+Note that is not an error for a successful call to transfer fewer bytes
+than requested (see
+.BR read (2)
+and
+.BR write (2)).
+
On error, \-1 is returned, and \fIerrno\fP is set appropriately.
.SH ERRORS
The errors are as given for
diff --git a/man2/sendfile.2 b/man2/sendfile.2
index 972564c..ef9ba6c 100644
--- a/man2/sendfile.2
+++ b/man2/sendfile.2
@@ -113,6 +113,7 @@ Note that a successful call to
.BR sendfile ()
may write fewer bytes than requested;
the caller should be prepared to retry the call if there were unsent bytes.
+See also NOTES.
On error, \-1 is returned, and
.I errno
@@ -166,6 +167,12 @@ Other UNIX systems implement
with different semantics and prototypes.
It should not be used in portable programs.
.SH NOTES
+.BR sendfile ()
+will transfer at most 0x7ffff000 (2,147,479,552) bytes,
+returning the number of bytes actually transferred.
+.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69
+(This is true on both 32-bit and 64-bit systems.)
+
If you plan to use
.BR sendfile ()
for sending files to a TCP socket, but need
diff --git a/man2/write.2 b/man2/write.2
index 90ef9b5..3e8c363 100644
--- a/man2/write.2
+++ b/man2/write.2
@@ -89,6 +89,10 @@ Note that not all filesystems are POSIX conforming.
.SH RETURN VALUE
On success, the number of bytes written is returned (zero indicates
nothing was written).
+It is not an error if this number is smaller than the number of bytes
+requested; this may happen for example because the disk device was filled.
+See also NOTES.
+
On error, \-1 is returned, and \fIerrno\fP is set
appropriately.
@@ -217,6 +221,14 @@ then the call fails with the error
.BR EINTR ;
if it is interrupted after at least one byte has been written,
the call succeeds, and returns the number of bytes written.
+
+On Linux,
+.BR read ()
+(and similar system calls) will transfer at most
+0x7ffff000 (2,147,479,552) bytes,
+returning the number of bytes actually transferred.
+.\" commit e28cc71572da38a5a12c1cfe4d7032017adccf69
+(This is true on both 32-bit and 64-bit systems.)
.SH BUGS
According to POSIX.1-2008/SUSv4 Section XSI 2.9.7
("Thread Interactions with Regular File Operations"):
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
