All of lore.kernel.org
 help / color / mirror / Atom feed
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 19:57:16 +0900	[thread overview]
Message-ID: <87o81x0wdv.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <CAHuHWtk1-AdKoa-SBOb=sJAM=32reVzcUQYjrrxvOPYwFZJqXQ@mail.gmail.com> (Chung-Chiang Cheng's message of "Wed, 23 Mar 2022 18:27:43 +0800")

Chung-Chiang Cheng <shepjeng@gmail.com> writes:

> 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.

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.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

  reply	other threads:[~2022-03-23 10: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
2022-03-23 10:27         ` Chung-Chiang Cheng
2022-03-23 10:57           ` OGAWA Hirofumi [this message]
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=87o81x0wdv.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 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.