Chung-Chiang Cheng <shepjeng@xxxxxxxxx> writes: > 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. Yes, exactly. Although I think it is better, in real world userspace, it may got actual compatibility issue and reported, then we may have to revert even if I personally think new is better. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
