Закрытие файла...

← →
brother © (2011-12-22 20:01) [0]

Гарантирется ли закрытие файла и доступ к нему при конструкциях?:
...TStringList.Create; ...SaveToFile(s); ...Free;
и
TIniFile.Create... Write... ...Free;
просто есть код записи и чтения (в пределах одного приложения) в файлы этих типов, но потом, эти файлу ВРОДЕ как не доступны (возможно ли все еще заняты и до них нет доступа даже в режиме только чтение), или всеж надо искть баг в коде доступа открытия на чтение этих фалов)... надо выяснить, что к чему...

← →
И. Павел © (2011-12-23 08:36) [1]

> brother © (22.12.11 20:01)

Конструкции ведь обернуты в try/finally или with?

← →
han_malign (2011-12-23 09:03) [2]

> Конструкции ведь обернуты в try/finally

- надеюсь ошибки не маскируются безусловным try/except end?

> ...TStringList.Create;
> ...SaveToFile(s);
> ...Free;

- SaveToFile(s) - по отношению к файлу - атомарная оперция(в контексте одного потока, естественно)

TIniFile - использует WritePrivateProfileString() - функция также атомарна по отношению к файлу...

То есть - в обоих случаях время жизни объектов не важно...

← →
Anatoly Podgoretsky © (2011-12-23 15:29) [3]

Не гарантируется.

← →
Ega23 © (2011-12-23 15:35) [4]

> Не гарантируется.

Почему???
procedure TStrings.SaveToFile(const FileName: string; Encoding: TEncoding); var Stream: TStream; begin Stream := TFileStream.Create(FileName, fmCreate); try SaveToStream(Stream, Encoding); finally Stream.Free; end; end;

← →
Anatoly Podgoretsky © (2011-12-23 17:14) [5]

> Почему???

Потому что у него ни каких try finally нет

← →
Dennis I. Komarov © (2011-12-23 18:44) [6]

Вроде как сам TStrings к файлу то отношения не имеет. Я за Легыча [4].
А вот TIni - надо код показать...

← →
DVM © (2011-12-23 22:42) [7]

Я как то сталкивался с ситуациями, когда сразу (буквально следующей строкой) после кода аналогичного [4], файл оказывался залочен, причем намертво, на доли секунды и его нельзя было из того же потока вновь открыть на запись, удалить, переместить. Т.е файл вроде бы закрыт, но не свободен. Грешил на антивирусы. Проявлялось очень редко, благо не часто требуется сразу после закрытия файла что-то с ним делать.

← →
Rouse_ © (2011-12-23 23:16) [8]

Не гарантируется в любом случае...

← →
Dennis I. Komarov © (2011-12-23 23:26) [9]

> Rouse_ © (23.12.11 23:16) [8]

Эм... Обоснуй...

← →
Rouse_ © (2011-12-24 11:14) [10]

На память не вспомню, но в MSDN где-то было что файл буде залочен до окончания сброса буффера

← →
Dennis I. Komarov © (2011-12-24 13:42) [11]

> файл буде залочен до окончания сброса буффера

про какой буфер речь?

← →
Rouse_ © (2011-12-24 23:26) [12]

Что значит какой? Тот в который пишутся данные, они ж не напрямую на диск сразу идут...

> Что значит какой? Тот в который пишутся данные, они ж не
> напрямую на диск сразу идут...

Разумеется. Вот я и спросил, какой... Есть Кэш на винте, есть какая-нить прослойка в операционке, диск может быть как и на удаленной тачке и совсем не Win, так и на RAM диске...

Да какая разница какой, знание не поможет.

Спасибо - разобрался... можно считать, что гарантирует, ибо сброс с буфера на винт практически мгновенный...

> Конструкции ведь обернуты в try/finally

да

> [15] brother © (26.12.11 08:44)
> можно считать, что гарантирует, ибо сброс с буфера на винт
> практически мгновенный...

"Практически" не считается, если процедура закрытия файла возвращает управление до его освобождения.

Вообще на вскидку почему файл может быть залочен после вызова CloseHandle:
1. CloseHandle вернула ошибку
2. выполняется асинхронная операция записи/чтения
3. не скинут файловый кэш
4. количество дескрипторов на файл не равно нулю.
5. изменились права доступа к файлу

В втором и третьем случае CloseHandle не ждет окончания операции...
Еще нужно почитать Соломона/Руссиновича, там точно было что-то по этому поводу, но искать лениво...

Закрытие файла... Найти похожие ветки