linux-ext4 - Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]

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 for Android: free password hash cracker in your pocket

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

Message-ID: <AANLkTimdFCGSKLn7aGMpBMIauHTsHY7hpAAmpo6uTcnD@mail.gmail.com>
Date:	Thu, 22 Jul 2010 09:40:22 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeremy Allison <jra@...ba.org>
Cc:	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 9:27 AM, Jeremy Allison <jra@...ba.org> wrote:
> On Thu, Jul 22, 2010 at 08:47:46AM -0700, Linus Torvalds wrote:
>> Tell me why we shouldn't just do this right?
>
> No, ctime isn't the same as Windows "create time".

Umm. What kind of reading problems do you guys have?

I know effin well that ctime isn't the same as Windows create time.
THAT WAS MY POINT.

But the fact is, th Unix ctime semantics are insane and largely
useless. There's a damn good reason almost nobody uses ctime under
unix.

So what I'm suggesting is that we have a flag - either per-process or
per-mount - that just says "use windows semantics for ctime".

And yes, I'm very aware that the "c" in ctime doesn't stand for
"create". But anybody who points that out is - once more - totally
missing the point. My point is that we have three timestamps, and
windows wants three timestamps (somebody claims that NTFS has four
timestamps, but the Windows file time access functions certainly only
shows three times, so any potential extra on-disk times have no
relevance because they are invisible to pretty much everybody). We can
have unix semantics for mtime/atime/ctime, or we can have windows
semantics for those three values.

So let's say that we introduce a mount flag that says
"ctime=winctime", which basically just sets a flag that instead of
changing ctime on chmod/chown/etc, it just changes mtime instead (or,
as mentioned, we could make it a process flag instead).

Let's face it, Unix semantics are not sacred.  Especially not
something like ctime, which is pretty damn useless. If you're a samba
server, why not just say "let's do ctime the way windows does creation
times", and let it be at that?

I personally think that Unix ctime is insane. There is no real reason
why "write()" should change mtime, but "chmod" changes ctime. It was
just a random decision way back when, and it's clearly not what samba
wants, and it's equally clearly not what even most _unix_ people want
(just google for "ctime" and "creation time", and watch the confusion
- exactly because unix semantics are simply _random_ and odd semantics
in this area)

I would not be at all surprised if it turns out that people might want
to really turn ctime into creation time (with the mount flag or
whatever) even if they are _not_ running samba.

An added issue is that most filesystems simply don't have more than
three times (and some obviously have not even that, but that's true in
Windows too). So re-using ctime actually means that this scheme would
work a whole lot better than some crazy xstat() interface that doesn't
support common filesystems anyway.

                                         Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html