[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinmV7YuRof7dZGDmbXR_7J2hz2Z_DtsDu54dUGo@mail.gmail.com>
Date: Thu, 22 Jul 2010 10:32:31 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jim Rees <rees@...ch.edu>
Cc: Jeremy Allison <jra@...ba.org>, Volker.Lendecke@...net.de,
David Howells <dhowells@...hat.com>,
Jan Engelhardt <jengelh@...ozas.de>,
linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended
file stats available [ver #6]
On Thu, Jul 22, 2010 at 10:12 AM, Jim Rees <rees@...ch.edu> wrote:
>
> I believe it was done that way so "dump" could backup just the inode and not
> the data if only the inode had changed. Full history here:
>
> http://blog.plover.com/Unix/ctime.html
Yes, the dump reasoning makes sense, and that history also shows that
originally chmod just changed mtime (since that's the _sane_ thing to
do). So if it wasn't for dump - that nobody uses any more and that was
considered a hack even back when and never supported things like
xattrs etc - unix probably wouldn't have a ctime at all (or would have
implemented a "creation time" because people would have asked for it).
So I'm sure there are reasons for ctime. That just doesn't mean that
it's really "good", the same way there were reasons to name "creat()"
without the "e".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists