[Samba] strange behavior with "dos filetime resolution = yes"

[Jeremy Allison]

On Tue, Jan 26, 2016 at 11:57:58AM +0100, Hubert Gilch wrote:
> Hello,
> 
> i see a strange behavior with timestamps of files on a samba share
> (4.2.6 on SLES 12 SP1 and 4.1.8 on Ubuntu 14.04) with "dos filetime
> resolution = yes": On older samba versions, windows properties
> dialogue correctly shows only even seconds, but (at least) the two
> indicated versions show sometimes even and sometimes odd seconds if
> the file has on the server filesystem a timestamp with second.
> 
> on SLES (file has odd seconds in timestamp):
>  # l --full-time fsclean_kunde.sh
> -rwxrwxr-x 1 relag relag 1930 2016-01-21 18:08:41.280635200 +0100
> fsclean_kunde.sh*
> 
> on Windows 7 (seconds should be 40!):
> T:\projekte\relag4i\RelagSystem\cmd>ls -l --full-time
> T:\projekte\relag4i\RelagSystem\cmd\fsclean_kunde.sh
> -rw-r--r--    1 hubert   Administ     1930 Thu Jan 21 17:08:41 2016
> T:\projekte\relag4i\RelagSystem\cmd\fsclean_kunde.sh
> 
> But when you view properties via Windows Explorer, it reports
> alternately 41 and 40 seconds.
> 
> In my understanding, "dos filetime resolution = yes" should have the
> effect that only even seconds are reported by samba (and in older
> 3.x version this is the case).
> 
> smb.conf (only the relevant share):
> [RELAG]
>         force group = relag
>         force user = relag
>         # inherit acls = Yes
>         path = /relag
>         create mask = 0775
>         directory mask = 0775
>         follow symlinks = yes
>         wide links = yes
>         read only = No
>         dos filemode = Yes
>         dos filetimes = Yes
>         dos filetime resolution = Yes
>         fake directory create times = yes
>         map archive = no

Can you get a wireshark trace when you're asking
for the properties ? The lp_dos_filetime_resolution()
check isn't widely used or tested so there might
be a path through that no longer does the rounding.

Seeing what call is being made should help track
that down.

Cheers,

	Jeremy.