Bug 10908 - spoolss SetJob document_name changes are not retained for GetJob
spoolss SetJob document_name changes are not retained for GetJob
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Printing
unspecified
All All
: P5 normal
: ---
Assigned To: printing-maintainers
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-10-30 16:27 UTC by David Disseldorp
Modified: 2016-11-16 16:47 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Disseldorp 2014-10-30 16:27:05 UTC
With bug#10905 fixed, the print_test_extended smbtorture test now passes, however it still throws the following warning, which is not encountered when run against a Windows server:

WARNING!: document_name did *NOT* change from 'smbprn.46TLrR' to 'any_other_docname'

The corresponding client test code block is:

 3552                 info1.document_name     = new_document_name;
...
 3565                 torture_assert(tctx,
 3566                         test_SetJob(tctx, b, handle, info[i].info1.job_id, &ctr, 0),
 3567                         "failed to call test_SetJob level 1");
 3568 
 3569                 torture_assert(tctx,
 3570                         test_GetJob_args(tctx, b, handle, info[i].info1.job_id, 1, &ginfo),
 3571                         "failed to call test_GetJob");
 3572 
 3573                 if (strequal(ginfo.info1.document_name, document_name)) {
 3574                         torture_warning(tctx,
 3575                                         "document_name did *NOT* change from '%s' to '%s'\n",
 3576                                         document_name, new_document_name);
 3577                 }

This shows that the document name change requested via SetJob is not carried in subsequent GetJob response.

The SetJob code path updates the document name in the printer database via print_job_set_name(). However, the separate printer queue state is used in producing the GetJob response, which I believe leads to the inconsistency.
Comment 1 Andreas Schneider 2016-11-16 16:42:36 UTC
Any progress on that one? :-)
Comment 2 David Disseldorp 2016-11-16 16:47:35 UTC
(In reply to Andreas Schneider from comment #1)
> Any progress on that one? :-)

Sorry, I don't think I got anywhere with this one.