All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chung-Chiang Cheng <shepjeng@gmail.com>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
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 18:27:43 +0800	[thread overview]
Message-ID: <CAHuHWtk1-AdKoa-SBOb=sJAM=32reVzcUQYjrrxvOPYwFZJqXQ@mail.gmail.com> (raw)
In-Reply-To: <87sfr917hr.fsf@mail.parknet.co.jp>

OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> 於 2022年3月23日 週三 下午2:57寫道:
>
> Chung-Chiang Cheng <shepjeng@gmail.com> 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.

  reply	other threads:[~2022-03-23 10:27 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
2022-03-23 10:27         ` Chung-Chiang Cheng [this message]
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='CAHuHWtk1-AdKoa-SBOb=sJAM=32reVzcUQYjrrxvOPYwFZJqXQ@mail.gmail.com' \
    --to=shepjeng@gmail.com \
    --cc=cccheng@synology.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=kernel@cccheng.net \
    --cc=linux-fsdevel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.