I have found that when Windows spooler sends print file to SAMBA it
may send packets with non-sequential order but with correct offsets.
Samba supports non-sequential SMB offset for file shares well, but
doesn't support it at all for the SMB printing. I guess that this is
the critical bug because sometimes Windows sends print file in "out of
order" SMB blocks.
It proves by Ethereal captures were we can see SMB blocks sent to print share
out of sequential order.
How to reproduce it:
I have prepared special file with running ASCI number and copy this file to
Samba print share. I have made empty "print command" for keeping this file in
spool directory. I have calculated MD5 sum for the Linux and Window copy of
this file. Sometimes it's differnt, and in this case you can see that two data
block were swapped. I have made a capture (by ethereal) and found that it
happen on wire (Windows did it). Samba never supports out of order SMB block
for printing. I beleive it's mandatory.
Created attachment 1233 [details]
Plain text export from ethereal capture file
There are 4 sequential write requests with out of order offsets.
File data has running ASCI numbers for simple calculation were swap was.
No no no!!!! This is completely and utterly USELESS !!!!
Please attach the *RAW* ethereal capture data. The text output is worse than
useless. If it's too big send it to me directly or make it available over the
web. People, *PLEASE NEVER SEND TEXT CAPTURE FILES* !! What do you think we can
do with them ?
jeremy, if the fix you checked in is complete, please close this bug. thanks.
I think this bug is now fixed in SVN.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.