Chung-Chiang Cheng <shepjeng@xxxxxxxxx> writes: >> Yes, ctime is issue (include compatibility issue when changing) from >> original author of this driver. And there is no perfect solution and >> subtle issue I think. >> >> I'm not against about this change though, this behavior makes utimes(2) >> behavior strange, e.g. user can change ctime, but FAT forget it anytime, >> because FAT can't save it. >> >> Did you consider about those behavior and choose this? > > 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. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
