为什么文件属性中的“访问时间”和“修改时间”不一致？

转http://greenerycn.cnblogs.com/

在Win7下，我注意到一个现象，就是经常文件属性中的“访问时间”和“修改时间”是不一致的，如下图：

这个文件是我在21:41 创建的，然后我在21:42修理里面的内容并保存。按照常理，访问时间应该和修改时间一致才对。现象是反而比修改时间早，很奇怪。

根据GetFileTime这个API，和文件相关的时间有3个：

BOOL WINAPI GetFileTime(
  __in       HANDLE hFile,
  __out_opt  LPFILETIME lpCreationTime,
  __out_opt  LPFILETIME lpLastAccessTime,
  __out_opt  LPFILETIME lpLastWriteTime
);

CreationTime:创建时间，很好理解，就是这个文件创建时的时间。

LastAccessTime:最后访问时间，表示文件读取，写入，复制或者执行的最后时间.

LastWriteTime:  文件最后写入的时间。

从这个定义来看的话，LastAccessTime应该大于等于LastWriteTime.但是从使用来看的话，却又不是这样的。

Why?

今天看了The Old New Thing才明白过来，原来从2003 SP1起，为了性能，默认把LastAccessTime给禁用了。

我使用的是Win7系统，默认是关闭的。

那么它为什么会影响性能呢？

LastAccessTime会保存到两个地方：

• 文件属性中，作为MFT中的一条记录
• 该文件所属的目录索引中。

影响性能的主要原因是如果一个文件只是读操作的话，为了更新这个时间，就必须做一个写操作，把该信息写入到文件属性和目录索引中去，这样一个读操作就变成了一个读+写操作。由于现在的硬盘都非常大，几十万个文件都是常事，如果读操作再加一个写操作，那么这个确实影响性能。（详细可以参考Fsutil: behavior 中对于DisableLastAccess的描述，地址附后）。

下面是各个文件系统对文件时间的支持文档：

说明：

1.NTFS 本身是支持更新LastAccessTime,在Windows 2000,XP,2003中默认是开启的，Vista之后需要单独开启。

如何开启LastAccessTime的更新呢？

使用命令查询当前系统是否关闭了LastAccessTime的更新：

fsutil behavior query disablelastaccess

1 表示关闭，0表示开启

关闭LastAccessTime的更新：

fsutil behavior set disablelastaccess 1

注意：需要重启。

打开LastAccessTime的更新：

fsutil behavior set disablelastaccess 0

注意：需要重启。

事实上，上面的修改都是修改的注册表

Key: [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlFileSystem] 
Value Name: NtfsDisableLastAccessUpdate 
Data Type: REG_DWORD (DWORD Value) 
Value Data: (0 = disable, 1 = enable)

用python获取的方法为:

我们通过文件属性的获取，os.stat() 方法：
 
>>> import os
>>> statinfo=os.stat(r"C:/1.txt")
>>> statinfo
(33206, 0L, 0, 0, 0, 0, 29L, 1201865413, 1201867904, 1201865413)
使用os.stat的返回值statinfo的三个属性获取文件的创建时间等
st_atime (访问时间), st_mtime (修改时间), st_ctime（创建时间），例如，取得文件修改时间：
>>> statinfo.st_mtime
1201865413.8952832
这个时间是一个linux时间戳，需要转换一下
使用time模块中的localtime函数可以知道：
>>> import time
>>> time.localtime(statinfo.st_ctime)
(2008, 2, 1, 19, 30, 13, 4, 32, 0)
2008年2月1日的19时30分13秒（2008-2-1 19:30:13）