From: Viacheslav Dubeyko <slava@dubeyko.com>
To: 李扬韬 <frank.li@vivo.com>,
"Viacheslav Dubeyko" <Slava.Dubeyko@ibm.com>,
"glaubitz@physik.fu-berlin.de" <glaubitz@physik.fu-berlin.de>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: 回复: 回复: [PATCH 2/2] hfs: fix to update ctime after rename
Date: Wed, 14 May 2025 18:10:26 -0700 [thread overview]
Message-ID: <44bdd2c97a8c91acb4b7e101f85f9a261b6c5cbc.camel@dubeyko.com> (raw)
In-Reply-To: <SEZPR06MB5269F2CCD9AD085D2712842FE895A@SEZPR06MB5269.apcprd06.prod.outlook.com>
On Sat, 2025-05-10 at 05:31 +0000, 李扬韬 wrote:
> Hi Slava,
>
> > If I understood correctly "ERROR: access time has changed for file1
> > after remount" means atime has been changed.
>
> In fact, it seems that it is not the atime that has been changed, but
> the disk atime that has been not changed.
> The inode in memory has a newer atime, but the atime is not updated
> to the disk when write_inode is executed(hfs has no atime in disk
> format).
>
> For ERROR: access time has changed for file1 after remount
>
> Before:
> Access: 2025-05-09 14:05:40
> Modify: 2025-05-09 14:05:38
> Change: 2025-05-09 14:05:38
>
> After umount&mount:
> Access: 2025-05-09 14:05:38 <-- back to mtime
> Modify: 2025-05-09 14:05:38
> Change: 2025-05-09 14:05:38
>
> So we get inconsistent results for atime.
>
> Am I missing something?
>
This is was my point. We need to make the access time (atime) always
the same as the modification time (mtime) because we cannot save the
atime on disk. This is what I meant by atime == mtime. And this atime
change is happening in HFS driver logic that needs to be corrected.
Thanks,
Slava.
next prev parent reply other threads:[~2025-05-15 1:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 20:15 [PATCH 1/2] hfsplus: " Yangtao Li
2025-04-29 20:15 ` [PATCH 2/2] hfs: " Yangtao Li
2025-04-29 21:31 ` Viacheslav Dubeyko
2025-05-02 0:03 ` Viacheslav Dubeyko
2025-05-07 14:22 ` 回复: " 李扬韬
2025-05-09 17:51 ` Viacheslav Dubeyko
2025-05-09 19:02 ` Viacheslav Dubeyko
2025-05-10 5:31 ` 回复: " 李扬韬
2025-05-15 1:10 ` Viacheslav Dubeyko [this message]
2025-04-29 21:27 ` [PATCH 1/2] hfsplus: " Viacheslav Dubeyko
2025-05-01 12:01 ` 回复: " 李扬韬
2025-05-01 18:57 ` Viacheslav Dubeyko
2025-05-01 19:10 ` John Paul Adrian Glaubitz
2025-05-01 19:48 ` Viacheslav Dubeyko
2025-05-02 12:52 ` Theodore Ts'o
2025-05-05 22:31 ` Viacheslav Dubeyko
2025-05-02 0:07 ` Viacheslav Dubeyko
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=44bdd2c97a8c91acb4b7e101f85f9a261b6c5cbc.camel@dubeyko.com \
--to=slava@dubeyko.com \
--cc=Slava.Dubeyko@ibm.com \
--cc=frank.li@vivo.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®