This was discovered, and the correction tested, on a, i386 Linux box, kernel 2.4.18.
Samba
version is 2.7.7a, patched from 2.2.6 pristine source.
In smbd/reply.c reply_writebraw:
The return value from write_file is compared to numtowrite, an unsigned value.
If the write failed, returning -1, the comparison sees it as the max unsigned value,
and the failure isn't detected. The Windoze box user sees no write error, but the file
later turns out to have zero size or content. Later on a debug message about a
presumed mis-estimate
of the write size is logged at level 3 or above, but otherwise ignored.
This mismatch is apparently an oversight, since similar writes and checks elsewhere
in the same file properly cast the unsigned numtowrite to signed before checking.
This merely brings this case into agreement with them.
The FIXME? message is just a suggestion to handle the off chance that future changes
to the code might cause some confusion there. No code changes there.
This change has been compiled and tested, and works as expected.
(If this isn't the right way to submit a patch, please enlighten me. This one is so
short that
I don't imagine it should be a problem.)
--- reply.c Tue Dec 31 00:45:00 2002
+++ reply.c Tue Dec 31 00:48:27 2002
@@ -2673,5 +2673,5 @@
fsp->fnum, (double)startpos, (int)numtowrite, (int)nwritten,
(int)write_through));
- if (nwritten < numtowrite) {
+ if (nwritten < (ssize_t) numtowrite) {
END_PROFILE(SMBwritebraw);
return(UNIXERROR(ERRHRD,ERRdiskfull));
@@ -2707,5 +2707,5 @@
exit_server("secondary writebraw failed");
}
-
+/* FIXME? Pedantically defensive progrmming might call for a second check for
+(nwritten < 0) here. */
if (tcount > nwritten+numtowrite) {
DEBUG(3,("Client overestimated the write %d %d %d\n",
Ray Simard
[EMAIL PROTECTED]
