Когда я вызываю FileInfo(path).LastAccessTime или FileInfo(path).LastWriteTime в файл, который находится в процессе записи, он возвращает время создания файла, а не последний раз, когда он был записан (т.е. сейчас).
Есть ли способ получить эту информацию?
Изменить: ко всем ответам до сих пор. Я не пробовал Refresh(), но это тоже не делается. Мне возвращено время, когда файл был начат для записи. То же самое касается статического метода и создания нового экземпляра FileInfo.
У Codymanix может быть ответ, но я не использую Windows Server (используя Windows 7), и я не знаю, где будет тестироваться параметр.
Изменить 2: Никто не считает интересным, что эта функция не работает?
Значения FileInfo загружаются только один раз и затем кэшируются. Чтобы получить текущее значение, вызовите Refresh() до получения свойства:
f.Refresh();
t = f.LastAccessTime;
Другой способ получить текущее значение - использовать статические методы класса File:
t = File.GetLastAccessTime(path);
Из MSDN:
При первом вызове FileSystemInfo вызовы Обновить и вернуть кэшированную информацию об API-интерфейсах атрибуты и т.д. На последующих звоните, вы должны позвонить Refresh, чтобы получить последняя копия информации.
Если вы используете приложение, которое делает запись, я думаю, вам придется "прикоснуться" к файлу, установив свойство LastWriteTime самостоятельно между каждым буфером данных, которые вы пишете. Некоторые psuedocode:
while(bytesWritten < totalBytes)
{
bytesWritten += br.Write(buffer);
myFileInfo.LastWriteTime = DateTime.Now;
}
Я не уверен, как сильно это повлияет на производительность записи.
В Windows есть настройка, которая иногда устанавливается особенно на серверных системах, так что измененные и доступные времена для файлов не установлены для лучшей производительности.
Начиная с Windows Vista, последнее время доступа по умолчанию не обновляется. Это улучшает производительность файловой системы. Вы можете найти здесь:
Чтобы повторно использовать последнее время доступа на компьютере, вы можете запустить следующую команду:
набор правил fsutil disablelastaccess 0
Вы пытались позвонить Refresh() непосредственно перед доступом к свойству (чтобы избежать получения кешированного значения)? Если это не сработает, посмотрите, что показывает Explorer одновременно? Если Explorer показывает неправильную информацию, то, возможно, это то, что вы действительно не можете адресовать - может быть, информация обновляется только тогда, когда дескриптор файла закрыт, например.
Как отметил Джеймс, LastAccessTime не обновляется.
LastWriteTime также претерпевает изменения с Vista. Когда процесс имеет файл, все еще открыт, а другой процесс проверяет LastWriteTime, он не увидит новое время записи в течение длительного времени, пока процесс не завершит файл. В качестве обходного пути вы можете открыть и закрыть файл из внешнего процесса. После этого вы можете попробовать прочитать LastWriteTime, а затем обновить значение.
Если приложение реализует нечто вроде скользящего регистратора, который закрывает файл, а затем переименовывает его в другое имя файла, вы также сталкиваетесь с проблемами, поскольку время создания и размер файла "старого" файла запоминаются ОС, хотя вы создали новый файл. Это включает неправильные отчеты о размере файла, даже если вы повторно создали log.txt с нуля, размер которого по-прежнему равен 0 байтам. Эта функция называется OS File System Tunneling, которая все еще присутствует в Windows 8.1. Пример того, как реализовать эту проблему, проверьте RollingFlatFileTracelistener из Enterprise Library (http://home.elka.pw.edu.pl/~mrudnik/CREAM/Logging/Src/Logging/TraceListeners/RollingFlatFileTraceListener.cs).
Вы можете увидеть эффекты туннелирования файловой системы на вашей собственной машине из командной оболочки cmd.
echo test > file1.txt
ren file1.txt file2.txt
Wait one minute
echo test > file1.txt
dir /tc file*.txt
...
05.07.2015 19:26 7 file1.txt
05.07.2015 19:26 7 file2.txt
Файловая система - это конечный автомат. Правильно синхронизировать состояния хранения сложно, если вы заботитесь о производительности и правильности. Этот странный туннельный синдром, очевидно, все еще используется приложением, которое, например, автосохранение файла и переместите его в место сохранения, а затем снова создайте файл в том же месте. Для этих приложений он имеет смысл дать файлу новую дату создания, потому что он был только скопирован. Некоторые инсталляторы также делают такие трюки, чтобы временно перемещать файлы в другое место и записывать содержимое позже, чтобы пройти мимо какого-либо файла, существует проверка наличия некоторых крючков установки.
Ответ Tommy Carlier заставил меня думать...
Хорошим способом визуализации различий является отдельный запуск двух фрагментов (я просто использовал LinqPAD), как показано ниже, а также для запуска монитора процессов sysinternals.
while(true)
File.GetLastAccessTime([file path here]);
и
FileInfo bob = new FileInfo(path);
while(true){
string accessed = bob.LastAccessTime.ToString();
}
Если вы посмотрите на Process Monitor во время запуска первого фрагмента, вы увидите попытки повторного и постоянного доступа к файлу для процесса LinqPAD. Второй фрагмент будет выполнять первоначальный доступ к файлу, для которого вы увидите активность на мониторе процесса, а затем очень мало потом.
Однако, если вы перейдете и измените файл (я только что открыл текстовый файл, который я отслеживал с помощью FileInfo, добавил символ и сохранил), вы увидите последовательность попыток доступа процесса LinqPAD к файлу в мониторе процесса.
Это иллюстрирует не кэшированное и кэшированное поведение двух разных подходов соответственно.
Будет ли не кэшированный подход носить отверстие на жестком диске?!
ИЗМЕНИТЬ
Я ушел, чувствуя себя умным над своим тестированием, а затем использовал поведение кеширования FileInfo в моей службе Windows (в основном, чтобы сидеть в цикле и говорить "Has-file-changed-has-file-changed..." раньше обработка)
Несмотря на то, что этот подход работал в моей dev-блоке, он не работал в рабочей среде, то есть процесс просто продолжал работать независимо от того, был ли файл изменен или нет. Я в конечном итоге изменил свой подход к проверке и просто использовал GetLastAccessTime как часть этого. Не знаю, почему это будет вести себя по-другому на производственном сервере... но я не слишком обеспокоен в этот момент.