【发布时间】：2015-02-09 15:41:39
【问题描述】：
我有一个小 C# 脚本，用于将我的开发文件夹备份到我的 Dropbox 文件夹，比较每个文件的源和目标 FileInfo.LastWriteTime，然后在需要时执行 File.Copy。
我注意到，新创建的文件不仅按预期在脚本的以下运行中被复制，而且在之后的运行中也被复制，尽管在此期间没有被修改。
第一次复制每个文件时，LastModifiedDate 似乎被四舍五入到最接近的秒数，使其下次看起来比原始文件更旧。在下一次运行时，文件会再次被复制，但现在 LastModifiedDate 不会向下舍入，即使文件实际上已被修改，所以从那时起一切都按预期工作。
谁能解释这里发生了什么？
更新：
似乎只影响某些文件类型，.png 就是其中之一。这个问题可以用下面的代码来演示：
var source = @"c:\temp\test.png";
var target = @"C:\Users\Me\Dropbox\test.png";
Console.WriteLine(File.GetLastWriteTime(source).ToString("HH:mm:ss.fff"));
Console.WriteLine(File.GetLastWriteTime(target).ToString("HH:mm:ss.fff"));
File.Copy(source, target, true);
Console.WriteLine(File.GetLastWriteTime(source).ToString("HH:mm:ss.fff"));
Console.WriteLine(File.GetLastWriteTime(target).ToString("HH:mm:ss.fff"));
第一次运行我们得到：
17:29:01.618 (source)
00:00:00.000 (target doesn't exist yet)
17:29:01.618 (source unchanged)
17:29:01.618 (target as source)
第二次运行：
17:29:01.618 (source unchanged)
17:29:01.000 (target has been rounded down)
17:29:01.618 (source unchanged)
17:29:01.618 (target as source again)
第三次及以后的运行：
17:29:01.618 (source unchanged)
17:29:01.000 (target still as source - no rounding down)
17:29:01.618 (source unchanged)
17:29:01.618 (target as source)
更新：
Procmon 显示 Dropbox.exe 在初始复制大约三秒后执行 SetBasicInformationFile 操作，这似乎是发生更改的时间，尽管 Procmon 没有将文件时间显示到毫秒。
由于它似乎只影响图形文件，我认为这与 Dropbox 缩略图生成有关，但我真的看不出他们这样做的任何充分理由，尤其是当他们在下次复制时间戳时保持完整.
【问题讨论】：
-
您在使用 Dropbox API 吗？或者只是在本地文件系统上移动文件？如果是后者，我不确定这里是否真的存在编程问题。
-
为什么针对文件系统而不是 API 的编程问题更少？无论如何，我都会承认它处于边缘。无论如何，它是文件系统，如问题中所述。
-
嗨@Plutonix，这很有趣，但如果它应该包含任何有助于解决问题的内容，我就错过了。
-
For example, the resolution of create time on FAT is 10 milliseconds, while write time has a resolution of 2 seconds and access time has a resolution of 1 day, so it is really the access date.
标签： c# windows file backup dropbox