From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Chung-Chiang Cheng <shepjeng@gmail.com>
Cc: Chung-Chiang Cheng <cccheng@synology.com>,
linux-fsdevel@vger.kernel.org, kernel@cccheng.net
Subject: Re: [PATCH 2/2] fat: introduce creation time
Date: Wed, 23 Mar 2022 15:57:20 +0900 [thread overview]
Message-ID: <87sfr917hr.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <CAHuHWtkvt4wOdwaoyYv0B4862pSYttMBh6BUz3vHbERv+CEGaw@mail.gmail.com> (Chung-Chiang Cheng's message of "Wed, 23 Mar 2022 10:14:14 +0800")
Chung-Chiang Cheng <shepjeng@gmail.com> 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@mail.parknet.co.jp>
next prev parent reply other threads:[~2022-03-23 6:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-21 9:58 [PATCH 1/2] fat: split fat_truncate_time() into separate functions Chung-Chiang Cheng
2022-03-21 9:58 ` [PATCH 2/2] fat: introduce creation time Chung-Chiang Cheng
2022-03-22 7:33 ` OGAWA Hirofumi
2022-03-23 2:14 ` Chung-Chiang Cheng
2022-03-23 6:57 ` OGAWA Hirofumi [this message]
2022-03-23 10:27 ` Chung-Chiang Cheng
2022-03-23 10:57 ` OGAWA Hirofumi
2022-03-25 7:38 ` Chung-Chiang Cheng
2022-03-25 10:36 ` OGAWA Hirofumi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sfr917hr.fsf@mail.parknet.co.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=cccheng@synology.com \
--cc=kernel@cccheng.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=shepjeng@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).