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.
jeremy, if the fix you checked in is complete, please close this bug. thanks.
I think this bug is now fixed in SVN. Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.