[PATCH] exfat: preserve creation times during rename

[PATCH] exfat: preserve creation times during rename

[Hungyu Lin]

exfat_rename() resets the destination parent directory's i_crtime after
every successful rename. A normal mv within that directory therefore
changes its STATX_BTIME, and the new creation time is also written to
disk. Moving a child does not recreate its parent directory.

The function also resets i_crtime on an overwritten target inode. An
application holding an open file descriptor can observe its birth time
change even though it still refers to the same inode.

Remove both creation-time updates. simple_rename_timestamp() already
updates the modification and change times required by rename, while
creation times should remain unchanged. Jeff Layton questioned these
updates during the timestamp accessor conversion, but they remain in
the current implementation.

Fixes: 5f2aa075070c ("exfat: add inode operations")
Suggested-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/bb698e294b0d4dbbbad4b94048693360010b8010.camel@kernel.org
Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
---
 fs/exfat/namei.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index 68ddb9c5504f..d01280570f70 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -1293,7 +1293,6 @@ static int exfat_rename(const struct mnt_idmap *idmap,
 
 	inode_inc_iversion(new_dir);
 	simple_rename_timestamp(old_dir, old_dentry, new_dir, new_dentry);
-	EXFAT_I(new_dir)->i_crtime = current_time(new_dir);
 	exfat_truncate_inode_atime(new_dir);
 	if (IS_DIRSYNC(new_dir) && size != i_size_read(new_dir))
 		exfat_sync_inode(new_dir);
@@ -1331,7 +1330,6 @@ static int exfat_rename(const struct mnt_idmap *idmap,
 			exfat_warn(sb, "abnormal access to an inode dropped");
 			WARN_ON(new_inode->i_nlink == 0);
 		}
-		EXFAT_I(new_inode)->i_crtime = current_time(new_inode);
 	}
 
 unlock:
-- 
2.43.0

Re: [PATCH] exfat: preserve creation times during rename

[Jeff Layton]

On Tue, 2026-10-27 at 09:13 +0000, Hungyu Lin wrote:
> exfat_rename() resets the destination parent directory's i_crtime after
> every successful rename. A normal mv within that directory therefore
> changes its STATX_BTIME, and the new creation time is also written to
> disk. Moving a child does not recreate its parent directory.
> 
> The function also resets i_crtime on an overwritten target inode. An
> application holding an open file descriptor can observe its birth time
> change even though it still refers to the same inode.
> 
> Remove both creation-time updates. simple_rename_timestamp() already
> updates the modification and change times required by rename, while
> creation times should remain unchanged. Jeff Layton questioned these
> updates during the timestamp accessor conversion, but they remain in
> the current implementation.
> 
> Fixes: 5f2aa075070c ("exfat: add inode operations")
> Suggested-by: Jeff Layton <jlayton@kernel.org>
> Link: https://lore.kernel.org/r/bb698e294b0d4dbbbad4b94048693360010b8010.camel@kernel.org
> Signed-off-by: Hungyu Lin <dennylin0707@gmail.com>
> ---
>  fs/exfat/namei.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
> index 68ddb9c5504f..d01280570f70 100644
> --- a/fs/exfat/namei.c
> +++ b/fs/exfat/namei.c
> @@ -1293,7 +1293,6 @@ static int exfat_rename(const struct mnt_idmap *idmap,
>  
>  	inode_inc_iversion(new_dir);
>  	simple_rename_timestamp(old_dir, old_dentry, new_dir, new_dentry);
> -	EXFAT_I(new_dir)->i_crtime = current_time(new_dir);
>  	exfat_truncate_inode_atime(new_dir);
>  	if (IS_DIRSYNC(new_dir) && size != i_size_read(new_dir))
>  		exfat_sync_inode(new_dir);
> @@ -1331,7 +1330,6 @@ static int exfat_rename(const struct mnt_idmap *idmap,
>  			exfat_warn(sb, "abnormal access to an inode dropped");
>  			WARN_ON(new_inode->i_nlink == 0);
>  		}
> -		EXFAT_I(new_inode)->i_crtime = current_time(new_inode);
>  	}
>  
>  unlock:

To be clear, i_crtime is equivalent to the btime, so it shouldn't
change on a rename.

Reviewed-by: Jeff Layton <jlayton@kernel.org>