OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> 於 2022年3月23日 週三 下午2:57寫道： > > Chung-Chiang Cheng <shepjeng@xxxxxxxxx> writes: > > > > > Yes. I think it's not perfect but a better choice to distinguish between > > change-time and creation-time. While change-time is no longer saved to > > disk, the new behavior maintains the semantic of "creation" and is more > > compatible with non-linux systems. > > Ok, right, creation time is good. But what I'm saying is about new ctime > behavior. > > Now, you allow to change ctime as old behavior, but it is not saved. Why > this behavior was preferred? > > Just for example, I think we can ignore ctime change, and define new > behavior is as ctime==mtime always. This will prevent time wrap/backward > etc. I got your point. Correctly speaking ctime is not really dropped but mixed with mtime after my patch. They share the same field on disk. Before that ctime is mixed with crtime. I choose this new behavior because ctime and mtime are similar concepts. ctime is the update time for file attributes, and mtime is the one for file contents. They are updated together most of the time with few exceptions (rename, rmdir, unlink) in the current FAT implementation. Thanks. > > Thanks.
