RE: [PATCH v4 1/3] hfsplus: fix to update ctime after rename

[Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>]

On Wed, 2025-07-23 at 03:32 +0100, Al Viro wrote:
> On Tue, Jul 22, 2025 at 01:13:45AM -0600, Yangtao Li wrote:
> 
> > @@ -552,9 +553,13 @@ static int hfsplus_rename(struct mnt_idmap *idmap,
> >  	res = hfsplus_rename_cat((u32)(unsigned long)old_dentry->d_fsdata,
> >  				 old_dir, &old_dentry->d_name,
> >  				 new_dir, &new_dentry->d_name);
> > -	if (!res)
> > -		new_dentry->d_fsdata = old_dentry->d_fsdata;
> > -	return res;
> > +	if (res)
> > +		return res;
> > +
> > +	new_dentry->d_fsdata = old_dentry->d_fsdata;
> 
> 	Umm...  Is that assignment (either before or after that patch)
> actually correct?
> 
> 	Note that new_dentry essentially got unlinked here; old_dentry
> is about to have its parent/name changed by the caller of ->rename(),
> so...  that looks very odd.
> 
> 	What is that line about?

So, as far as I can see, the dentry structure [1] has:

void *d_fsdata;			/* fs-specific data */

And HFS+ is using this field to store Catalog File's ID (CNID) of
the file or folder, for example [2]:

static inline void hfsplus_instantiate(struct dentry *dentry,
				       struct inode *inode, u32 cnid)
{
	dentry->d_fsdata = (void *)(unsigned long)cnid;
	d_instantiate(dentry, inode);
}

So, this line simply copies CNID from old_dentry->d_fsdata to
new_dentry->d_fsdata during the rename operation. I assume that
->fs_data should be untouched by generic logic of dentries processing.

Thanks,
Slava.

[1]
https://elixir.bootlin.com/linux/v6.16-rc6/source/include/linux/dcache.h#L108
[2] 
https://elixir.bootlin.com/linux/v6.16-rc7/source/fs/hfsplus/dir.c#L25