On Wed, Mar 23, 2022 at 6:57 PM OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> wrote: > > No, a user can change the ctime to arbitrary time, and after the your > patch, the changed ctime only hold on a memory inode. So a user sees > ctime jump backward and forward when a memory inode is expired. (Of > course, this happens just by "cp -a" in real world use case.) > > I'm pointing about this introduced new behavior by your patch. > As you mentioned, there are still some cases to consider that ctime isn't identical to mtime. If so, ctime won't be consistent after inode is expired because it will be filled with the value of on-disk mtime, which is weird and confusing. To solve the issue, I propose to keep ctime and mtime always the same in memory. If you agree with this approach, I'll send a v2 patch for it. Thanks.