Глючит DeleteFile в WinXP

← →
Loginov Dmitry © (2008-03-20 10:39) [0]

Если в программе FreeCommander выполняется просмотр файла на F3, то при попытке удаления данного файла функцией DeleteFile() будет возвращено значение True (функция FileExists, как и положено, вернет False), хотя файл на этот момент физически еще не удален. Он будет автоматически удален, как только закроется окно окно просмотра. Но до его закрытия ни одна программа не может создать/открыть данный файл - возникает ошибка:
File already exists. Permission denied. File: FileName Cannot access file. File: FileName

В справке на этот счет сказано:
The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. Windows Me/98/95: The DeleteFile function deletes a file even if it is open for normal I/O or as a memory-mapped file. To prevent loss of data, close files before you attempt to delete them.

Т.е. в WinXP подобной ошибки происходить не должно.

Ошибка происходит только при использовании просмоторщика от FreeCommander. Не знаю, каким образом там выполняется работа с файлами, но воспроизвести данную ошибку без помощи FreeCommander не удалось.

← →
Alien1769 © (2008-03-20 10:52) [1]

NTFS ?

← →
Riply © (2008-03-20 10:52) [2]

Не знаю что такое FreeCommander и как он работает, но причина может быть в следующем:
Если файл открыт, то он может не удаляться а "помечаться" на удаление (DeletePending ставиться в True).
Соответственно и DeleteFile и FileExists вертнут, то что от них ожидается.
Но реально файл будет удален только после закрытия Handle.
А пока он не закрыт попытка создания нового файла и выдаст ошибку: File already exists

← →
Игорь Шевченко © (2008-03-20 11:00) [3]

любой нормальный просмотрщик открывает файл функциями CreateFileMapping и MapViewOfFile

ты можешь сымитировать это поведение и убедиться, что если функция CreateFile вызвана с флагом FILE_SHARE_DELETE, то после вызова CreateFileMapping и MapViewOfFile файл нельзя ни удалить, ни создать, а после вызова UnmapViewOfFile файл можно удалить, но нельзя создать.

> Глючит DeleteFile в WinXP

DeleteFile в WinXP не глючит. Глючат как всегда кривые руки и лазание в справку после, а не до.

← →
Loginov Dmitry © (2008-03-20 11:00) [4]

> NTFS ?

FAT 32

> Если файл открыт, то он может не удаляться а "помечаться"
> на удаление (DeletePending ставиться в True).
> Соответственно и DeleteFile и FileExists вертнут, то что
> от них ожидается.
> Но реально файл будет удален только после закрытия Handle.
>
> А пока он не закрыт попытка создания нового файла и выдаст
> ошибку: File already exists

Ну это все в справке написано (только на английском :). А тогда как понимать:
The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file.
?

И что тогда такое normal I/O?

← →
Игорь Шевченко © (2008-03-20 13:38) [5]

Riply © (20.03.08 10:52) [2]

Для чего, по-твоему, существует флаг FILE_SHARE_DELETE ? Правильно, чтобы файл можно было удалить в то время, когда его кто-то открыл.

← →
guav © (2008-03-20 13:51) [6]

> [5] Игорь Шевченко © (20.03.08 13:38)
> Правильно, чтобы файл можно было удалить в то время, когда
> его кто-то открыл.

При этом файл не будет фактически удалён, пока существуют открытые хендлы.
Вызов DeleteFile имеет те же результаты, что вызов ZwSetInformationFile с FileDispositionInformation с TRUE в FILE_DISPOSITION_INFORMATION::DeleteFile.

← →
Игорь Шевченко © (2008-03-20 13:53) [7]

guav © (20.03.08 13:51) [6]

А вот скажи мне, для NTFS, если в момент между удалением файла и закрытием хендла для этого файла в другом процессе произойдет выключение питания, что будет с файлом после перезагрузки ?

← →
guav © (2008-03-20 14:18) [8]

> [7] Игорь Шевченко © (20.03.08 13:53)

Проверил, как я и ожидал файл снова появился.

← →
guav © (2008-03-20 14:27) [9]

> [8] guav © (20.03.08 14:18)

Возможно, это результат отмены незафиксированной операции через Log File Service, но я думаю, что файл просто никогда не удалялся, пока хендл был жив. Проверка какой из этих вариантов имеет место займёт больше времени, потому проверять сейчас не буду, уверен что второй.

← →
{RASkov} © (2008-03-20 14:30) [10]

> [9] guav © (20.03.08 14:27)
> потому проверять сейчас не буду, уверен что второй

Зачем проверять если уверен? ;) :)

← →
guav © (2008-03-20 14:40) [11]

> [10] {RASkov} © (20.03.08 14:30)

Таки проверил. И убедился что файл даже не начинает удалятся.

← →
Игорь Шевченко © (2008-03-20 15:03) [12]

guav © (20.03.08 14:40) [11]

Удаление файла есть удаление упоминания о нем из MFT (для NTFS) и из файла, описывающего каталог.

Что есть "файл начал удаляться" ?

← →
{RASkov} © (2008-03-20 15:06) [13]

> [11] guav © (20.03.08 14:40)
> Таки проверил.

Ну вот.... сам себе не веришь :(
:о) Или проверка не подтвердилась?... я просто не в курсе чем вы тут занимаетесь...) чуть-чуть пооФФтопил... к сожалению :(

← →
guav © (2008-03-20 15:08) [14]

> [12] Игорь Шевченко © (20.03.08 15:03)
> Удаление файла есть удаление упоминания о нем из MFT (для
> NTFS) и из файла, описывающего каталог.

Обычно не только это, но и ещё некоторые операции.

> [12] Игорь Шевченко © (20.03.08 15:03)
> Что есть "файл начал удаляться" ?

Что в $LogFile появились записи об названых и/или других операциях удаления.

← →
Игорь Шевченко © (2008-03-20 16:22) [15]

guav © (20.03.08 15:08) [14]

> Что в $LogFile появились записи об названых и/или других
> операциях удаления.

Таки да. Любопытно, как на других файловых системах

> Игорь Шевченко (20.03.2008 16:22:15) [15]

На Линуксе можешь удалять любой файл, а дальше на везение.

> [15] Игорь Шевченко © (20.03.08 16:22)

Подозреваю что поведение везде одинаковое, т.е. драйверы всех файловых систем на Windows NT based системе должны обеспечивать такое поведение. Завтра могу глянуть FAT.
Что означает фраза из MSDN "The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file." мне тоже не понятно.

guav © (20.03.08 22:21) [17]

А чего тут непонятного ? Файл может быть открыт двумя способами, либо CreateFile (без указания FILE_SHARE_DELETE, разумеется) либо CreateFile (без указания FILE_SHARE_DELETE, разумеется) + CreateFileMapping с последующим CloseHandle хендла, полученного от CreateFile.

> т.е. драйверы всех файловых систем на Windows NT based системе
> должны обеспечивать такое поведение

А каким образом FAT обеспечит восстановление метаданных после сбоев, если это не журналируемая система ? Если бы такое поведение было возможно, то и незачем было бы NTFS изобретать.

> [18] Игорь Шевченко © (20.03.08 22:30)

Про это "разумеется" там явно не указали, вот и вводит в заблуждение

> А каким образом FAT обеспечит восстановление метаданных
> после сбоев, если это не журналируемая система ?

Что-то я не понял.
То что я проверил и утверждаю - файл не удаляется пока последний хендл не закрыт. Это обеспечивается драйвером ФС а не самой ФС.
Кстати, на FAT вполне можно обепечить восстановление метаданных после сбоев, причём без журналирования - см. TFAT.

guav © (20.03.08 23:06) [19]

> То что я проверил и утверждаю - файл не удаляется пока последний
> хендл не закрыт.

Давай так проведем: в одной программе откроется файл с FILE_SHARE_DELETE, в другой он удалиться и спросится, существует ли он ?
А потом, не закрывая первую, нажмем Reset и посмотрим, что станет с файлом.
На NTFS и на FAT

Я с тобой не спорю, мне интересно.

На NTFS проделано следующее:
Создаём в блокноте файл test.txt
Запускаем консольное приложение примерно следущего содерания CreateFile("c:\test.txt", GENERIC_ALL, FILE_SHARE_DELETE, nil, OPEN_EXISTING, 0, 0); Sleep(INFINITE);
Файл удаляем в проводнике. Вроде исчез, но когда снова заходим в ту папку он на месте.
Создаём и удаляем другие файлы, не закрывая приложение. Нажимаем Reset. Новые изменения видны, файл test.txt не удалён.
Снова запускаем консольное приложение и удаляем файл. Закрываем приложение и файл удаляется.

Могу для ясности то же самое на FAT проделать.

Глючит DeleteFile в WinXP Найти похожие ветки