Flapping notify tests
douglas.bagnall at catalyst.net.nz
Wed Oct 31 01:45:16 UTC 2018
On 29/08/18 9:14 AM, Andrew Bartlett via samba-technical wrote:
> G'Day Jeremy,
> Following up from our recent phone call and your gallant offer to
> assist, here are some notify failures I've seen recently that I would
> love to see resolved, as they flap reasonably often:
> UNEXPECTED(failure): samba3.smb2.notify.dir(nt4_dc)
> REASON: Exception: Exception: (../source4/torture/smb2/notify.c:394) wrong value for notify.smb2.out.num_changes 0x9 should be 0xa
> (../source4/torture/smb2/util.c:158) change_time not setup correctly: Thu Sep 13 12:56:06 2018 CEST(131813097660000000) => Mon Nov 12 11:56:06 2018 CET(131864937660000000)
We had another one of these this week, and I looked because I thought it
might have something to do with sn-devel falling out of daylight savings
time (it seems not).
We have had this 9 times in 2018, and 3 in 2016. Never in odd numbered
The gap between the times:
> CEST(131813097660000000) => Mon Nov 12 11:56:06 2018 CET(131864937660000000)
is always 60 days (or to be precise, 51840000000000 NT time units, in
this case the daylight savings boundary making it look one hour less).
It is always change_time that fails. The test goes like this:
> unix_to_nt_time(&setfile.basic_info.in.create_time, t + 9*30*24*60*60);
> unix_to_nt_time(&setfile.basic_info.in.access_time, t + 6*30*24*60*60);
> unix_to_nt_time(&setfile.basic_info.in.write_time, t + 3*30*24*60*60);
> unix_to_nt_time(&setfile.basic_info.in.change_time, t + 1*30*24*60*60);
And you'll see change_time + 60 days is write_time. So change_time is
for some reason being set to write_time.
I can't see how that is happening, though.
More information about the samba-technical