On Mon, Apr 29, 2024 at 2:59 PM Jeremy Allison <jra@xxxxxxxxx> wrote: > > On Mon, Apr 29, 2024 at 09:27:15PM +0200, Ralph Boehme wrote: > >On 4/29/24 7:17 PM, Jeremy Allison wrote: > >> > >>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. :) > > That wasn't the point of the change I'd guess (although > it's from 2009, so who can remember :-). > > >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> > > Yep. This is the right thing to do going forward. Let's > see what breaks. Remember, 2009 was way before we had > any good time tests. Another test to try is xfstest generic/728 (which checks that ctime is updated on setxattr) and xfstest generic/236 (checking that ctime is updated when hardlink updated, where I originally found this bug) -- Thanks, Steve
