Ошибка доступа к файлу делфи

    Процесс не может получить доступ к файлу, так как этот файл занят другим процессом… Но это не точно… Как показала практика, для программы на Delphi это действительно не точно.
    При открытии файла в режиме «только для чтения» в параметре определяющем режим доступа к файлу обычно передают комбинацию «fmOpenRead or fmShareDenyNone». Но оказалось, что это избавляет только от части ошибок «Процесс не может получить доступ к файлу, так как этот файл занят другим процессом» или «The process cannot access the file because it is being used by another process».
    Для начала немного теории. В Delphi режим доступа к файлу, определяется комбинацией константы режима открытия файла (fmOpen*) и константы разделения доступа к файлу (fmShare*). Эти константы описанны в модуле System.SysUtils. Приведу их значение для ОС Windows:

    Теперь перейдем к практике. Попробуем в режиме fmOpenRead открыть все файлы в каталоге для хранения временных файлов (там большая вероятность встретить файл, который занят какими-нибудь процессом).

Вариант 1. Откроем файлы без указания режима разделения доступа

try
  with TFileStream.Create(sFileName, fmOpenRead) do
    try
      // читаем секретные материалы
    finally
      Free
    end;
except
  on E: Exception do
    Writeln(E.Message);
end;

У меня в каталоге для хранения временных файлов нашлось 23 файла, которые заняты какими-то процессами.

Вариант 2. Откроем файлы в режиме разделения доступа «fmShareDenyNone»

try
  with TFileStream.Create(sFileName, fmOpenRead or fmShareDenyNone) do
    try
      // истина где-то рядом
    finally
      Free
    end;
except
  on E: Exception do
    Writeln(E.Message);
end;

Теперь получаем 16 файлов занятых другими процессами и радуемся улучшению результата. Радуемся, но не долго. Некоторые из этих «занятых» файлов открываются на просмотр в «Lister» из Total Commander! Как так?!?

Метод TFileStream.Create приводит к функции FileOpen из System.SysUtils:

function FileOpen(const FileName: string; Mode: LongWord): THandle;
const
  AccessMode: array[0..2] of LongWord = (
    GENERIC_READ,
    GENERIC_WRITE,
    GENERIC_READ or GENERIC_WRITE);
  ShareMode: array[0..4] of LongWord = (
    0,
    0,
    FILE_SHARE_READ,
    FILE_SHARE_WRITE,
    FILE_SHARE_READ or FILE_SHARE_WRITE);
begin
  Result := INVALID_HANDLE_VALUE;
  if ((Mode and 3) <= fmOpenReadWrite) and
    ((Mode and $F0) <= fmShareDenyNone) then
    Result := CreateFile(PChar(FileName), AccessMode[Mode and 3],
      ShareMode[(Mode and $F0) shr 4], nil, OPEN_EXISTING,
      FILE_ATTRIBUTE_NORMAL, 0);
end;

Получается, что в режиме разделения доступа fmShareDenyNone функция CreateFile вызывается с параметром dwShareMode = FILE_SHARE_READ or FILE_SHARE_WRITE. Согласно документации от Microsoft, в WinAPI, кроме FILE_SHARE_READ и FILE_SHARE_WRITE, есть еще режим разделения доступа FILE_SHARE_DELETE. В Delphi константа FILE_SHARE_DELETE описана в модуле Winapi.Windows, но не используется.

Откроем файл для нашего потока сами с учетом FILE_SHARE_DELETE:

var
  h: THandle;
...
h := CreateFile(PChar(sFileName),
                GENERIC_READ,
                FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE,
                nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
if h = INVALID_HANDLE_VALUE
  then Writeln(SysErrorMessage(GetLastError))
  else with TFileStream.Create(h) do
         try
           // X-файлы наши!
         finally
           Free
         end;

Оказывается, что у меня в каталоге для хранения временных файлов реально только 4 файла занятых другими процессами!

В результате я добавил себе в проект функцию

function FileOpenAsReadOnly(const sFileName: String): THandle;
begin
  Result := CreateFile(PChar(sFileName),
                       GENERIC_READ,
                       FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE,
                       nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
  if Result = INVALID_HANDLE_VALUE then
    raise EFOpenError.CreateResFmt(@SFOpenErrorEx, 
                                   [ExpandFileName(sFileName), 
                                   SysErrorMessage(GetLastError)])
end;

и использовал ее для открытия файлов в режиме «только для чтения»:

TFileStream.Create(FileOpenAsReadOnly(sFileName))

    Конечно, полностью победить эту ошибку мне не удалось, но 4 файла против 23 или 16 — это тоже хорошее достижение. Интересно, то, что разработчики из Borland потеряли FILE_SHARE_DELETE, а разработчики из Embarcadero не нашли — это ошибка в Delphi? Или так надо, и я чего-то не понимаю?

Нравится ресурс? Помоги проекту!

ошибка доступа к файлу
, или как закрыть файл принудительно?

• Подписаться на тему
• Сообщить другу
• Скачать/распечатать тему

Сообщ. #1 , 27.01.08, 02:08
Junior Рейтинг (т): 1	Пытаюсь сохранить значение TStringList в файл с помощью TStringlist.SaveToFile() Но иногда вылетает ошибка доступа к файлу — пишет что файл уже открыт другим процессом. Т.е. иногда все работает, а иногда нет Как тогда принудительно закрыть файл, перед сохранением? P.S. С этим файлом я работаю только через TStringList.SaveToFile() и TWebBrowser.Navigate().

ViktorXP	Сообщ. #2 , 27.01.08, 06:43
	try    MyStringlist.SaveToFile(‘кудато в небытие’); except    ShowMessage(‘Закрой файл, а то глаз выколю!!’);    // тут можна сказать левой процедуре чобы та закрыла свой доступ и дала дорогу молодым)))    // а потом вызвать процедуру повтора end; Добавлено 27.01.08, 06:45 просто закрыть файл не зная хендл трудновато будет)))

tyoma_first

Сообщ. #3 , 27.01.08, 12:28

Junior Рейтинг (т): 1

Я именно так и делаю. Меня как раз интересует момент // тут можна сказать левой процедуре чобы та закрыла свой доступ и дала дорогу молодым))) // а потом вызвать процедуру повтора Какую процедуру использовать или как написать свою? Напомню что я с этим файлом работаю только с помощью TStringList.SaveToFile() и TWebBrowser.Navigate(). Может быть TWebBrowser держит файл открытым? Если да — то как ему сказать что файлы закрывать надо?..

ViktorXP	Сообщ. #4 , 27.01.08, 17:35
	Ну веб браузер не использует постоянно страничку попробуй добавить какойто флаг и перед загрузкой в вебраузер ставить его в истину а в событии OnDocumentComplete ставить его в лож а уже перед сохранением из TStringList проверять илиже перед сохранением зделать WebBrowser1.Stop; чтобы он прекратил загружать страничку

tyoma_first	Сообщ. #5 , 01.02.08, 22:27
Junior Рейтинг (т): 1	Цитата ViktorXP @ 27.01.08, 17:35 илиже перед сохранением зделать WebBrowser1.Stop; чтобы он прекратил загружать страничку делал — не помогает

simsergey	Сообщ. #6 , 02.02.08, 09:46
	Цитата ViktorXP @ 27.01.08, 06:43 ShowMessage(‘Закрой файл, а то глаз выколю!!’); Гениально! Надо себе в прогу засунуть

ViktorXP	Сообщ. #7 , 03.02.08, 08:12
	tyoma_first ну тада показывай весь исходник походу у тебя еще чтото файл ковыряет

tyoma_first	Сообщ. #8 , 03.02.08, 19:18
Junior Рейтинг (т): 1	Нее.. исходник там очень большой (бывший дипломный проект ). Так что даже если выложу — придется много разбираться Тем не менее спасибо за советы, я нашел решение другим путем (загружаю в webbrowser напрямую, без сохранения в файл).

0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)

0 пользователей:

• Предыдущая тема
• Delphi: Общие вопросы
• Следующая тема

[ Script execution time: 0,0292 ]   [ 16 queries used ]   [ Generated: 30.01.23, 06:42 GMT ]  

It is not AssignFile() that fails, but your call to Rewrite() on a file with the Hidden attribute set. Following explains it:

Typically you call Rewrite(F) in order to erase the file and write new data to it with subsequent Write(F, ...) or WriteLn(F, ...) calls.

From docs (System.Rewrite):

If an external file with the same name already exists, it is deleted
and a new empty file is created in its place.

There is no problem opening the file for writing with the Append() command.

(Based on above I drew the conclusion that it is the deletion that fails with the Access denied message. That was cutting the corners too much.)

Beaten by comments I traced through the code and compared actual code with MSDN documentation for CreateFile:

Actual code:

// if mode is fmOutput (as it is for Rewrite)
OpenMode = GENERIC_WRITE
Flags = CREATE_ALWAYS
// ...
Temp := CreateFile(t.Name, OpenMode, FILE_SHARE_READ, nil, Flags, FILE_ATTRIBUTE_NORMAL, 0);

And documentation:

If CREATE_ALWAYS and FILE_ATTRIBUTE_NORMAL are specified, CreateFile
fails and sets the last error to ERROR_ACCESS_DENIED if the file
exists and has the FILE_ATTRIBUTE_HIDDEN or FILE_ATTRIBUTE_SYSTEM
attribute.

Calling Rewrite() on a existing file with the hidden attribute fails always.

It is not AssignFile() that fails, but your call to Rewrite() on a file with the Hidden attribute set. Following explains it:

Typically you call Rewrite(F) in order to erase the file and write new data to it with subsequent Write(F, ...) or WriteLn(F, ...) calls.

From docs (System.Rewrite):

If an external file with the same name already exists, it is deleted
and a new empty file is created in its place.

There is no problem opening the file for writing with the Append() command.

(Based on above I drew the conclusion that it is the deletion that fails with the Access denied message. That was cutting the corners too much.)

Beaten by comments I traced through the code and compared actual code with MSDN documentation for CreateFile:

Actual code:

// if mode is fmOutput (as it is for Rewrite)
OpenMode = GENERIC_WRITE
Flags = CREATE_ALWAYS
// ...
Temp := CreateFile(t.Name, OpenMode, FILE_SHARE_READ, nil, Flags, FILE_ATTRIBUTE_NORMAL, 0);

And documentation:

If CREATE_ALWAYS and FILE_ATTRIBUTE_NORMAL are specified, CreateFile
fails and sets the last error to ERROR_ACCESS_DENIED if the file
exists and has the FILE_ATTRIBUTE_HIDDEN or FILE_ATTRIBUTE_SYSTEM
attribute.

Calling Rewrite() on a existing file with the hidden attribute fails always.