Samba server installed by ArcaOS corrupts print file rendering printout useless.

[jjw]

I have two HP Lasetjet printers: an HP2100 connected to my office desktop, an ASUS Z97-K, via LPT1 using a PCI parallel port card and the modified PRINT01.SYS driver and an HP Color Laserjet CP2025dn connected to my T60 widescreen via USB. Both printers can accept either PCL or Postscript and on both systems I am using the IBM Lasetjet and Postscript drivers with a Printer object for each personality. Both systems were running eCS2.2betaII until ArcaOS5.0 was released, and are now running ArcaOS5.0.1 with the previous eCS installations as maintenance partitions. ArcaOS is using version 3.6.25 of the server and eCS is using version 3.3.16. I do not know how to find out the version numbers of the clients.

When the first occasion arose to send a substantial printout from the desktop machine downstairs in the office to the HP CP2025dn Color Laserjet in the family room upstairs, the output was corrupted. Further investigation revealed that the direction of transmission didn't make any difference, i.e., a reasonably complex print job sent from the T60 upstairs to the HP2100 on the desktop in the office downstairs also failed to print correctly.

Over the last couple of weeks I have done a series of experiments that trace the progress of the printer specific file from the application program on the source machine to the printer on the destination machine and conclusively demonstrate that the corruption occurs during the transmission of the printer specific file (nnnnn.SPL) from x:\spool\printers on the source machine to, say, smbprn{.nnnnn}.UvWXyZ in boot:\mptn\etc\samba\spool\printerd on the destination machine where printers and printerd are the names of the OS/2 printer objects that correspond to the target printer on the source and destination machines respectively. Note that the spooler sequence number is sometimes included in the spoolfile name and sometimes not; I have been unable to figure out why. Moreover, trying all four combinations of source and destination operating system (ArcaOS5.0.1 or eCS2.2betaII) revealed that the corruption only occurs when the destination machine is running ArcaOS. Therefore the fault is in the component of the SMB driver that receives the file to be printed and places it in boot:\mptn\etc\samba\spool\printerd in version 3.6.25 of Samba server installed by ArcaOS.

I also looked into the differences between correct and corrupted pcl and ps files. The most obvious difference is that the character '0d'x has been inserted in the corrupt file just before every instance of the character '0a'x (including any that already had a '0d'x preceding them). The '0a'x characters in the correct file and the '0d0a'x pairs in the corrupt file respectively partition the files into '0a'x free sections. In cases I have examined, if the number of such sections is the same in both files, The length of each section in the corrupt file is always less than or equal to that of the corresponding section in the correct file; if the number of sections in each file is not the same, the correct file always has more sections than the corrupt file. In the first case, all of the instances I have checked where corresponding sections are the same length they compare identical. When the lengths differ by n bytes, the difference between the corresponding sections is consistent with the random omission of n characters from the shorter (corrupt) section. Similarly, the corrupt file having n fewer sections is accounted for by the random ommission of n '0a'x characters. These results suggest a flow control problem in addition to the '0d'x insertion problem..

It seems to me that these problems are much more likely in the OS2 port than in how ArcaOS installs Samba.

I have also discovered why smbprint.cmd or smbprint.exe (despite Herwig Bauernfeind's assertion to the contrary in smbprint.readme) fail to delete the spool file. I first installed Samba in Nov-Dec 2014, the smbprint.exe distributed at that time didn't work. I eventually found an smbprint.cmd at netlabs that couldn't possibly have worked, but from it I was able to deduce the call linkage and what the program was trying to do and write my own programs. What I came up with is a PL/I program, fil2prt.exe, that copies a printer specific file to any suitable OS/2 printer object using a command of the form "fil2prt /printer <printer-specific-file" and a REXX program, smbprint.cmd, that invokes fil2prt. Until now, smbprint.cmd used SysFileDelete to attempt to delete the spool file, but that didn't work. I modified smbprint.cmd to write the return code from SysFileDelete to print.log. The return code was 32 which is sharing violation. I next tried modifying smbprint.cmd to use SysSleep to wait 10 seconds and try again until it successfully deleted the file. This never happened and print.log was gaining "Return code = 32" lines at the rate of 6 per minute. Conclusion: some module in Samba, probably the one that invokes smbprint.* has an open handle referencing the spool file that it doesn't close until smbprint.* returns. For the nonce, I have replaced the SysFileDelete in smbprint.cmd with "'detach e:\cmd\doit.cmd erase 'directory()'\'spoolfile". Doit.cmd uses SysSleep to wait ten seconds then executes its argument and exits.

Copies of smbprint.cmd, doit.cmd, and fil2prt.pli are available upon request.

[Herwig Bauernfeind]

I suggest to try the smbspool.exe utility from the Samba 3.3.16 release package and retry with that. This will give us a valuable hint.

smbprint has not been specifically tested for the 3.6.25 release because in our point of view both CUPS and SLPR usage are better solutions for printing with Samba.

The delay before files are closed are specific to 3.6, so this has changed between 3.3.14 and 3.6.25 - this is a known issue.

[Herwig Bauernfeind]

​http://trac.netlabs.org/samba/changeset/1034

smbprint now waits until the spoolfile is really closed and deletes then.

[Herwig Bauernfeind]

ok, I can reproduce your problem. smbspool von ArcaOS is 3.3 and that definitely works. No further test from your side required.

[jjw]

Replying to herwigb:

​http://trac.netlabs.org/samba/changeset/1034

smbprint now waits until the spoolfile is really closed and deletes then.

I tried that and it doesn't work. With the version installed here, namely that distributed by and installed by ArcaOS5.0.1, that approach fails because the spoolfile isn't closed until after smbprint returns.