我有一个使用保存文件的程序。它需要加载最新的保存文件，但如果下一个最新的文件不可用或已损坏，则返回该文件。我可以使用windows文件创建时间戳来告诉它们的创建顺序吗？或者这不可靠吗？我这么问是因为"更改"的时间戳似乎不可靠。如果必须的话，我可以在名称中嵌入创建时间/日期，但如果可能的话，使用文件系统日期会更容易。
如果你有一个目录，里面满是任意和随机命名的文件，而"时间"是唯一的因素，那么建立一个与时间戳匹配的文件名可能更有意义，这样就不需要使用工具来查看它了。
2008_12_31_24_60_60_1000
这将是我对平面文件系统的建议。
有时，如果你有很多文件，你可能想把它们分组，例如：
2008/
2008/12/
2008/12/31
2008/12/31/00-12/
2008/12/31/13-24/24_60_60_1000
或者更大的
2008/
2008/12_31/
等等
（此外，如果你没有嵌入时间，你的其他区别是什么，你不能有一个空文件名，并且创建单调递增的序列要困难得多？需要信息）
"可靠"是什么意思？当你创建一个文件时，它会得到一个时间戳，这很有效。现在，时间戳的分辨率不一定很高——我认为在FAT16上是2秒。在FAT32和NTFS上，它可能是1秒。因此，如果你以每秒不到一个的速度保存文件，你应该会很好。请记住，用户可以任意更改时间戳值。如果您对此感到担忧，您将不得不将时间戳嵌入到文件本身中（尽管在我看来这将是ovekill）
当然，如果机器的用户是管理员，他们可以将当前时间设置为他们想要的任何时间，系统会很乐意用这个时间给文件加上时间戳。
因此，这完全取决于你试图如何处理这些信息。
Windows时间戳以UTC为单位。因此，如果您的时区发生变化（即夏令时开始或结束时），时间戳将向前/向后移动一小时。除此之外，还有大约2秒的准确性，没有理由认为时间戳是无效的，使用它们当然没问题。但我认为这是一种糟糕的做法，你可以简单地将时间戳放在名称中，甚至放在文件本身中。
如果系统时间因某种原因而更改怎么办？这看起来很方便，但也许其他版本号的计数会更好。
添加：一个类似的问题，但有数据库，在这里。
在删除和重新创建同名文件后，我遇到了一些文件创建时间的问题。
类似于GetFileInfoEx文档中的评论
重新创建文件后获取正确创建时间的问题
我尝试使用GetFileAttributesEx，然后获取的ftCreationTime字段得到的WIN32_FILE_ATTRIBUTE_DATA结构。它工作得很好一开始，但在我删除文件并重新创建后，它一直在提供在重新启动进程之前，我将使用已错误的原始值再一次同样的问题也发生在FindFirstFile API上。我使用Window 2003。
据说这与隧道有关
当您想重命名文件时，请尝试使用此选项
Path.Combine(ArchivedPath, currentDate + " " + fileInfo.Name))