Samba returning mtime for multiple time stamp fields

[Steve French]

Samba seems to be the only server with this bug (I tried it with and
without vfs_btrfs as well).  The test works to the other servers I
tried including Windows.

Windows server updates ctime on hardlinks, but Samba fails to update
the timestamps in this case since it looks like it populates both
ChangeTime (ctime) and LastWriteTime (mtime) based on mtime rather
than setting:    ChangeTime = ctime (and LastWriteTime = mtime).
Locally the mtime and ctime are correct on the Samba server, but
remotely it reports it wrong.

On Tue, May 9, 2023 at 3:54 PM Steve French <smfrench at gmail.com> wrote:
>
> I noticed a problem with Samba when running xfstest 236.
>
> xfstest/236 does
> touch file1
> stat file1
> ln file1 file2
> stat file2
>
> And checks to make sure ctime is updated.  Locally I can see the ctime
> is updated, but Samba reports the value of mtime in both mtime and
> ctime (and doesn't show the change to ctime which causes the test to
> fail)
>
> root at smfrench-ThinkPad-P52:/mnt2# stat /test/out1
>   File: /test/out1
>   Size: 0          Blocks: 8          IO Block: 4096   regular empty file
> Device: 10302h/66306d Inode: 552933716   Links: 2
> Access: (0777/-rwxrwxrwx)  Uid: ( 1000/smfrench)   Gid: ( 1000/smfrench)
> Access: 2023-05-09 15:49:37.000109800 -0500
> Modify: 2023-05-09 15:49:37.000109800 -0500
> Change: 2023-05-09 15:50:08.405799460 -0500
>  Birth: 2023-05-09 15:49:36.980131061 -0500
> root at smfrench-ThinkPad-P52:/mnt2# stat out1
>   File: out1
>   Size: 0          Blocks: 8          IO Block: 1048576 regular empty file
> Device: 35h/53d Inode: 226         Links: 2
> Access: (0777/-rwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2023-05-09 15:49:37.000109800 -0500
> Modify: 2023-05-09 15:49:37.000109800 -0500
> Change: 2023-05-09 15:49:37.000109800 -0500
>  Birth: 2023-05-09 15:49:36.980131000 -0500
>
> #  /usr/local/samba/sbin/smbd -V
> Version 4.19.0pre1-GIT-3633027e49a
>
>
> --
> Thanks,
>
> Steve



-- 
Thanks,

Steve