Samba ctime still reported incorrectly

[Ralph Boehme]

On 4/29/24 7:17 PM, Jeremy Allison wrote:
> On Mon, Apr 29, 2024 at 10:51:21AM +0200, Ralph Boehme wrote:
>> Hi Steve,
>>
>> On 4/28/24 9:41 PM, Steve French via samba-technical wrote:
>>> I did another test of the Samba server ctime bug on Samba master
>>> (4.21.0pre1) and Samba server is still broken in how it reports ctime.
>>> An example scenario is simple, creating a hardlink is supposed to
>>> update ctime on a file (and this works fine to Windows server and
>>> ksmbd etc) but Samba server mistakenly reports ctime as mtime (unless
>>> you mount with the "posix" mount option).  This e.g. breaks xfstest
>>> generic/236 when run to Samba
>>>
>>> More information is at:
>>> https://bugzilla.samba.org/show_bug.cgi?id=10883
>>
>> I wonder if this is a bug going back as far as 
>> c9dca82ed7757f4745edf6ee6048bd94d86c4dbc
>>
>> @Jeremy: do you remember why you chose to return mtime in 
>> get_change_timespec() and not ctime?
> 
> If you look closely at that commit, you'll see
> that it's actually not changing the logic that
> previously existed :-).

yeah, sure, but it was a decent refactoring so I was wondering whether 
you'd considered the actual logic you were touching was correct. :)

> 
> -       put_long_date_timespec(p, m_timespec); /* change time */
> +       put_long_date_timespec(p, c_timespec); /* change time */
> 
> Previously we were using m_timespec as change time,
> and c_timespec in this change now comes from:
> 
> +       c_timespec = get_change_timespec(fsp, smb_fname);
> 
> +struct timespec get_change_timespec(struct files_struct *fsp,
> +                               const struct smb_filename *smb_fname)
> +{
> +       return smb_fname->st.st_ex_mtime;
> +}
> 
> So I actually wasn't changing what we already were
> doing :-).
> 
> Now as to *why* we were using m_time instead of c_time,
> my guess is that we were trying to emulate NTFS
> semantics which were not documented or well understood at the
> time (where "the time" is probably prior to 2009 :-).

Hm, so what do we do? MS-FSA seems to indicate NTFS ctime has pretty 
much the same semantics as POSIX ctime:

2.1.1.3 Per File

LastChangeTime: The time that identifies when the file metadata or 
contents were last changed in the FILETIME format specified in [MS-FSCC] 
section 2.1.1.

Let's see how many tests complain:

<https://gitlab.com/samba-team/devel/samba/-/pipelines/1272333543>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20240429/9224a128/OpenPGP_signature.sig>