Prev: [PATCH 1/1] VIDEO: ivtvfb, remove unneeded NULL test
Next: [PATCH] i8042: add Gigabyte Spring Peak to dmi_noloop_table
From: Linus Torvalds on 22 Jul 2010 13:40
On Thu, Jul 22, 2010 at 10:12 AM, Jim Rees <rees(a)umich.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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Greg Freemyer on 22 Jul 2010 14:50
On Thu, Jul 22, 2010 at 2:21 PM, Benny Halevy <bhalevy(a)panasas.com> wrote:
> On Jul. 22, 2010, 20:24 +0300, Linus Torvalds <torvalds(a)linux-foundation.org> wrote:
>> On Thu, Jul 22, 2010 at 10:03 AM, Jan Engelhardt <jengelh(a)medozas.de> wrote:
>>>
>>> I beg to differ. ctime is not completely useless. It reflects changes on
>>> the inode for when you don't you change the content.
>>
>> Uh. Yes. Except that why is file metadata really different from file
>> data? Most people really don't care. And a lot of people have asked
>> for creation dates - and I seriously doubt that Windows people
>> complain a lot about the fact that there you have mtime for metadata
>> changes too.
>>
>> The point being that Unix ctime semantics certainly have well-defined
>> semantics, but they are in no way "better" than having a real creation
>> time, and are often worse.
>
> Yeah, having create time would be important.
> That said, having a non user-settable modify timestamp is crucial
> for quickly determining whether a file has changed.

How would "cp --archive" and a host of backup/restore tools work
without user-settable modify timestamps?

Or are you proposing another timestamp? I do computer forensics, I
like timestamps, but enough is enough.

Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Greg Freemyer on 22 Jul 2010 14:50
On Thu, Jul 22, 2010 at 1:24 PM, Linus Torvalds
<torvalds(a)linux-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-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Benny Halevy on 22 Jul 2010 16:00
On Jul. 22, 2010, 21:45 +0300, Greg Freemyer <greg.freemyer(a)gmail.com> wrote:
> On Thu, Jul 22, 2010 at 2:21 PM, Benny Halevy <bhalevy(a)panasas.com> wrote:
>> On Jul. 22, 2010, 20:24 +0300, Linus Torvalds <torvalds(a)linux-foundation.org> wrote:
>>> On Thu, Jul 22, 2010 at 10:03 AM, Jan Engelhardt <jengelh(a)medozas.de> wrote:
>>>>
>>>> I beg to differ. ctime is not completely useless. It reflects changes on
>>>> the inode for when you don't you change the content.
>>>
>>> Uh. Yes. Except that why is file metadata really different from file
>>> data? Most people really don't care. And a lot of people have asked
>>> for creation dates - and I seriously doubt that Windows people
>>> complain a lot about the fact that there you have mtime for metadata
>>> changes too.
>>>
>>> The point being that Unix ctime semantics certainly have well-defined
>>> semantics, but they are in no way "better" than having a real creation
>>> time, and are often worse.
>>
>> Yeah, having create time would be important.
>> That said, having a non user-settable modify timestamp is crucial
>> for quickly determining whether a file has changed.
>
> How would "cp --archive" and a host of backup/restore tools work
> without user-settable modify timestamps?
>
> Or are you proposing another timestamp? I do computer forensics, I
> like timestamps, but enough is enough.

mtime and atime are already user settable and archive programs use
this on the destination, but ctime would be different after
copy/restore.

When updating the archive, just comparing mtime to determine if the source
changed is problematic as it can be set to any value after the change,
but src.ctime would be greater than dest.ctime in this case.

With posix semantics (http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_07)
this is not perfect either as there can be false-positives when the file stat changed but
the file has not, e.g. when st_nlink changed.

Benny

>
> Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: tridge on 22 Jul 2010 21:10
Hi Linus,

> 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).

Not quite. The underlying structure available to Windows programmers
is this one:

typedef struct _FILE_BASIC_INFORMATION {
LARGE_INTEGER CreationTime;
LARGE_INTEGER LastAccessTime;
LARGE_INTEGER LastWriteTime;
LARGE_INTEGER ChangeTime;
ULONG FileAttributes;
} FILE_BASIC_INFORMATION, *PFILE_BASIC_INFORMATION;

See http://msdn.microsoft.com/en-us/library/ff545762%28v=VS.85%29.aspx

These are the definitions:

CreationTime
Specifies the time that the file was created.
LastAccessTime
Specifies the time that the file was last accessed.
LastWriteTime
Specifies the time that the file was last written to.
ChangeTime
Specifies the last time the file was changed.

You are right that the more commonly used APIs (such as
GetFileInformationByHandle()) omit the ChangeTime field in the return
value. The ChangeTime is also not visible via the normal Windows GUI
or command line tools.

But there are APIs that are used by quite a few programs that do get
all 4 timestamps. For example, GetFileInformationByHandleEx() returns
all 4 fields. I include an example program that uses that API to show
all the timestamps below.

and yes, we think that real applications (such as Excel), look at
these values separately.

The other big difference from POSIX timestamps is that the
CreationTime is settable on Windows, and some of the windows UI
behaviour relies on this.

Cheers, Tridge

PS: Sorry for coming into this discussion so late


/*
show all 4 file times
tridge(a)samba.org, July 2010
*/

#define _WIN32_WINNT 0x0600

#include <stdio.h>
#include <stdlib.h>
#include "windows.h"
#include "winbase.h"


static void FileTime(const char *fname)
{
HANDLE h;
FILE_BASIC_INFO info;
BOOL ret;

h = CreateFile(
fname, GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
0,
NULL
);
if (h == INVALID_HANDLE_VALUE) {
printf("Unable to open %s\n", fname);
exit(1);
}

ret = GetFileInformationByHandleEx(h, FileBasicInfo, &info, sizeof(info));

if (!ret) {
printf("Unable to get file information\n");
exit(1);
}

printf("CreationTime: %llu\n", (unsigned long long)info.CreationTime.QuadPart);
printf("LastAccessTime: %llu\n", (unsigned long long)info.LastAccessTime.QuadPart);
printf("LastWriteTime: %llu\n", (unsigned long long)info.LastWriteTime.QuadPart);
printf("ChangeTime: %llu\n", (unsigned long long)info.ChangeTime.QuadPart);

CloseHandle(h);
}

int main(int argc, char* argv[])
{
if (argc < 2) {
printf("Usage: filetime FILENAME\n");
exit(1);
}

FileTime(argv[1]);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: [PATCH 1/1] VIDEO: ivtvfb, remove unneeded NULL test
Next: [PATCH] i8042: add Gigabyte Spring Peak to dmi_noloop_table