Samba ctime still reported incorrectly

Jeremy Allison jra at samba.org
Mon Apr 29 17:17:03 UTC 2024


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 :-).

-       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 :-).



More information about the samba-technical mailing list