[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimwIq0pBhCeOjOVjB0yeM3JHOvzVoj9M4ui6al9@mail.gmail.com>
Date: Thu, 22 Jul 2010 08:47:46 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Volker.Lendecke@...net.de
Cc: 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 8:36 AM, Volker Lendecke
<Volker.Lendecke@...net.de> wrote:
>
> The nice thing about this is also that if this is supposed
> to be fully usable for Windows clients, the birthtime needs
> to be changeable. That's what NTFS semantics gives you, thus
> Windows clients tend to require it.
Ok. So it's not really a creation date, exactly the same way ctime
isn't at all a creation date.
And maybe that actually hints at a better solution: maybe a better
model is to create a new per-thread flag that says "do ctime updates
the way windows does them".
So instead of adding another "btime" - which isn't actually what even
windows does - just admit that the _real_ issue is that Unix and
Windows semantics are different for the pre-existing "ctime".
The fact is, windows has "access time", "modification time" and
"creation time" _exactly_ like UNIX. It's just that the ctime has
slightly different semantics in windows vs unix. So quite frankly,
it's totally insane to introduce a "birthtime", when that isn't even
what windows wants, just because people cannot face the actual real
difference.
Tell me why we shouldn't just do this right?
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
Powered by blists - more mailing lists