[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTiljnpUGmP-DYW_5CNtRmlL8rK1W2c8ncrin92dC@mail.gmail.com>
Date: Thu, 22 Jul 2010 14:41:01 -0400
From: Greg Freemyer <greg.freemyer@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jan Engelhardt <jengelh@...ozas.de>,
Jeremy Allison <jra@...ba.org>, Volker.Lendecke@...net.de,
David Howells <dhowells@...hat.com>,
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 1:24 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
<snip>
> and I seriously doubt that Windows people
> complain a lot about the fact that there you have mtime for metadata
> changes too.
But Windows doesn't work that way for I'm fairly sure.
Window's mtime is only affected by file content updates. (I don't
know about xattr updates).
If you look at the first and fourth rows of the table at:
http://blogs.sans.org/computer-forensics/2010/04/12/windows-7-mft-entry-timestamp-properties/
You see that there are a number of activities that update the "$STD
Info MFT Entry Modified Field" that don't update the "$STD Info
Modification Time"
Again, "$STD Info MFT Entry Modified Field" has semantics close to linux ctime.
And "$STD Info Modification Time" similar to mtime.
I don't know if there are APIs to present MFT Entry Modified to user
space or if Samba uses that info. I just know it's part of the
on-disk NTFS filesystem data.
Greg
--
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