linux-kernel - 回复: [PATCH v2 3/3] hfs: fix to update ctime after rename

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SEZPR06MB5269FF7D1C758B1A6E260F23E867A@SEZPR06MB5269.apcprd06.prod.outlook.com>
Date: Wed, 28 May 2025 16:50:33 +0000
From: 李扬韬 <frank.li@...o.com>
To: Viacheslav Dubeyko <Slava.Dubeyko@....com>, "glaubitz@...sik.fu-berlin.de"
	<glaubitz@...sik.fu-berlin.de>, "slava@...eyko.com" <slava@...eyko.com>
CC: "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject:
 回复: [PATCH v2 3/3] hfs: fix to update ctime after rename

Hi Slava,

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

This is not explicitly stated in the man page or anything like that, but it seems to be a rule generally followed by file systems. 
By the way, I did this experiment on apfs, and after the rename operation, the ctime changed.

> And we still continue to operate by atime [1-4]. Should we do something
> with it?

I looked at other filesystems marked as NOATIME (e.g. jffs2), and similar atime operations were still preserved.

Thx,
Yangtao