On Mon, Mar 10, 2025 at 10:12:43PM +0000, David Laight wrote:
> On Mon, 10 Mar 2025 09:58:28 -0400
> "Theodore Ts'o" <tytso@xxxxxxx> wrote:
>
> > On Mon, Mar 10, 2025 at 07:26:00AM +0000, Artem S. Tashkinov wrote:
> > >
> > > Why is it that the Linux kernel supports reading btime, but there's no
> > > syscall to change it? At least for ext4 there's the debugfs utility, but
> > > for other filesystems there's just nothing. And even debugfs is not a
> > > solution, since it requires root privileges and an unmounted/mounted RO
> > > filesystem.
> >
> > POSIX and Single Unix Specification also doesn't provide a way to
> > allow userspace to set ctime (inode change time). That's because the
> > definition of "change time" is defined to include the time to change
> > anything about the inode metadata --- including the inode timestamps.
> >
>
> I'm sure that hadn't used to be the case.
You are incorrect.
> But as some point the 'ctime' changed from something that was usually
> the file create time (for some definition of create) to a pretty useless
> time that is almost a waste of disk space.
Which point would that be, considering that v6 inodes have only two timestamps
(atime and mtime), while in v7 e.g. chmod() definitely does update ctime?
sys/sys4.c:chmod():
ip->i_flag |= ICHG;
...
iput(ip);
sys/iget.c:iput():
if(ip->i_count == 1) {
...
iupdat(ip, &time, &time);
sys/iget.c:iupdat():
if(ip->i_flag&ICHG)
dp->di_ctime = time;
And filesys(5) has this:
.I Di_ctime
records the time of last modification
to the inode or to the file, and is used
to determine whether it should be dumped.
... which ought to answer the question about the intended use of that thing.
Hopefully useful mnemonics for your next attempt at UNIX101:
A: Accessed
M: contents Modified
C: Changed in any way, including metadata
