Printing and Samba 2.2.3a

[Gerald Carter]

On Thu, 14 Feb 2002, Johannes Tyve wrote:

> We have had the same problem using Samba on Solaris 7. All printer
> driver information was lost during upgrade to 2.2.3a and reinstalling
> the drivers didn't work in some cases. Sometimes the eventlog on the

I've got to look at this problem still....

> client got filled with messages like (from Bernhard Hornung):
>
> > Print driver HP LaserJet 4100 PCL 6 for Windows NT x86 Version-2 was 
> > added or or updated. Files:-
> > \\HOMER\print$\W32X86\2\HPBF0422.DLL,
> > \\HOMER\print$\W32X86\2\HPBF0420.DLL,
> > \\HOMER\print$\W32X86\2\HPBF0424.PMD.

This event log message is really bogus as far as I can tell.  Here's an 
explanation as far as I can determine.

--------------------------------------------------
Explanation : I have done a lot of tests on this.  First, it is
important to know that when an NT client issues a SetXXX() call
(e.g. SetPrinterData()), the client spooler will immediately
follow up with the following series of calls
 
  * GetPrinter(level == 0) and notice the change_id has been
    modified.  As a result, it will begin to update its local
    cache.
 
  * GetPrinterDriver2()
  * NTcreate&X on every dependent file for the driver
  * TRANS2_FINDFIRST for every dependent file
  * close all dependent files
 
  * EnumForms()
  * EnumPrinterData()
 
The series of calls is executed whether the printer server is
a PSA or a Windows NT box.
 
Now the interesting part of this test is that if I copy the
driver files from the PSA to the NT print server and perform
the same sceanrio against the NT4 server, I get the same Event ID
20 entries in the System Log on the NT client.
 
There appears to be a 1 to 1 correspondence between each
GetPrinterDriver2() call and the Event ID 20.  Remember that the
GetPrinterDriver2() call is caused by the SetXXX() call followed
by the GetPrinter(level == 0).
 
The log entry appears to be linked to the fact that we cannot store
the creation time of the driver files and have to fake it based
on the modification time.  There also appears to be timestamp
held internally to a DLL.  I dunno.  Maybe NT is comparing
the creation timestamp to this internal timestamp?
 
If I run the tests using a different driver and files that have
always been stored on an NTFS file system and hence have a valid
creation time stamp, I see the same network traffic, but not the
System Log entries about updating the driver.  If I run this test
using the same driver from a PSA, I do see the log entries.
 
So in conclusion, the System Log entries ID 20 are bogus in that
no driver files are actually copied from the server to the
client.  Therre is no increase in network traffic.  The source
of the problem appears to be the fact that we cannot reliably
store the creation time of a file.
--------------------------------------------------------------








cheers, jerry
 ---------------------------------------------------------------------
 Hewlett-Packard                                     http://www.hp.com
 SAMBA Team                                       http://www.samba.org
 --                                            http://www.plainjoe.org
 "Sam's Teach Yourself Samba in 24 Hours" 2ed.      ISBN 0-672-32269-2
 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--