From: Viacheslav Dubeyko <slava@dubeyko.com>
To: Yangtao Li <frank.li@vivo.com>, glaubitz@physik.fu-berlin.de
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Slava.Dubeyko@ibm.com
Subject: Re: [PATCH v2 3/3] hfs: fix to update ctime after rename
Date: Tue, 27 May 2025 15:46:28 -0700 [thread overview]
Message-ID: <3bbf9fe0b5e4b2fa26e472533e16a31c9d480903.camel@dubeyko.com> (raw)
In-Reply-To: <20250519165214.1181931-3-frank.li@vivo.com>
On Mon, 2025-05-19 at 10:52 -0600, Yangtao Li wrote:
> Similar to hfsplus, let's update file ctime after the rename
> operation
> in hfs_rename().
>
Frankly speaking, I don't quite follow why should we update ctime
during the rename operation. Why do we need to do this? What is the
justification of this?
And we still continue to operate by atime [1-4]. Should we do something
with it?
Thanks,
Slava.
[1]
https://elixir.bootlin.com/linux/v6.15/source/fs/hfsplus/inode.c#L519
[2]
https://elixir.bootlin.com/linux/v6.15/source/fs/hfsplus/inode.c#L562
[3]
https://elixir.bootlin.com/linux/v6.15/source/fs/hfsplus/inode.c#L609
[4]
https://elixir.bootlin.com/linux/v6.15/source/fs/hfsplus/inode.c#L644
> W/O patch(xfstest generic/003):
>
> +ERROR: access time has not been updated after accessing file1 first
> time
> +ERROR: access time has not been updated after accessing file2
> +ERROR: access time has changed after modifying file1
> +ERROR: change time has not been updated after changing file1
> +ERROR: access time has not been updated after accessing file3
> second time
> +ERROR: access time has not been updated after accessing file3 third
> time
>
> W/ patch(xfstest generic/003):
>
> +ERROR: access time has not been updated after accessing file1 first
> time
> +ERROR: access time has not been updated after accessing file2
> +ERROR: access time has changed after modifying file1
> +ERROR: access time has not been updated after accessing file3
> second time
> +ERROR: access time has not been updated after accessing file3 third
> time
>
> Signed-off-by: Yangtao Li <frank.li@vivo.com>
> ---
> fs/hfs/dir.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/fs/hfs/dir.c b/fs/hfs/dir.c
> index 86a6b317b474..756ea7b895e2 100644
> --- a/fs/hfs/dir.c
> +++ b/fs/hfs/dir.c
> @@ -284,6 +284,7 @@ static int hfs_rename(struct mnt_idmap *idmap,
> struct inode *old_dir,
> struct dentry *old_dentry, struct inode
> *new_dir,
> struct dentry *new_dentry, unsigned int flags)
> {
> + struct inode *inode = d_inode(old_dentry);
> int res;
>
> if (flags & ~RENAME_NOREPLACE)
> @@ -296,14 +297,16 @@ static int hfs_rename(struct mnt_idmap *idmap,
> struct inode *old_dir,
> return res;
> }
>
> - res = hfs_cat_move(d_inode(old_dentry)->i_ino,
> - old_dir, &old_dentry->d_name,
> + res = hfs_cat_move(inode->i_ino, old_dir, &old_dentry-
> >d_name,
> new_dir, &new_dentry->d_name);
> - if (!res)
> - hfs_cat_build_key(old_dir->i_sb,
> - (btree_key
> *)&HFS_I(d_inode(old_dentry))->cat_key,
> - new_dir->i_ino, &new_dentry-
> >d_name);
> - return res;
> + if (res)
> + return res;
> +
> + hfs_cat_build_key(old_dir->i_sb, (btree_key *)&HFS_I(inode)-
> >cat_key,
> + new_dir->i_ino, &new_dentry->d_name);
> + inode_set_ctime_current(inode);
> + mark_inode_dirty(inode);
> + return 0;
> }
>
> const struct file_operations hfs_dir_operations = {
next prev parent reply other threads:[~2025-05-27 22:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 16:52 [PATCH v2 1/3] hfsplus: " Yangtao Li
2025-05-19 16:52 ` [PATCH v2 2/3] hfs: correct superblock flags Yangtao Li
2025-05-27 22:36 ` Viacheslav Dubeyko
2025-05-28 16:37 ` 回复: " 李扬韬
2025-05-28 21:26 ` Viacheslav Dubeyko
2025-05-29 2:25 ` Yangtao Li
2025-05-30 5:21 ` Christian Brauner
2025-05-30 7:50 ` Yangtao Li
2025-05-28 16:56 ` 回复: " 李扬韬
2025-05-28 17:04 ` Viacheslav Dubeyko
2025-05-19 16:52 ` [PATCH v2 3/3] hfs: fix to update ctime after rename Yangtao Li
2025-05-27 22:46 ` Viacheslav Dubeyko [this message]
2025-05-28 1:37 ` Viacheslav Dubeyko
2025-05-28 16:50 ` 回复: " 李扬韬
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=3bbf9fe0b5e4b2fa26e472533e16a31c9d480903.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®