Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TerminateProcess

Страницы: < 1 2 3 4 5 6 7 >
Суслик © (2005-04-25 14:53:00)
Добрый день.

Есть такой псевдокод:

... запись в файл 200 мб из памяти sleep(500); TerminateProcess(GetCurrentProcess);

Вопрос: почему система ждет, когда файл запишется и только потом приложение закрывается? Вернее, почему файл оказывается записанным?

ЗЫ. win2000 server, диски ntfs и fat32.

mgcr (2005-04-29 15:46:00) [21]

> Весь вопрос - где про это написано.

Ты эта...не притворяйся write only, если не трудно. Пост № 13 прочитай.

Суслик (2005-04-29 15:41:00) [22]

> [114] Sha © (29.04.05 14:05)

"чудеса бывают"
(с) опытный программист (где-то вчера прочел)

Длинные строки в дельфи потокобезопасные. ДинМассивы тоже. Т.е. это значит, что строка не будет неконсистентной (с системной точки зрения) при многопоточном использовании - например, не оказется, что длина строки, одна а на самом деле выделено памяти другое количество. Также и с массивами.

Но это же ребята из борланда потрудились. Не сделай они этого - валились бы строки из нескольких потоков с нашими любимыми AV. Запросто.

Наверняка в файлах авторы тоже потрудились. Так, чтобы данные не смогли остаться неконсистентными при выключении. Весь вопрос - где про это написано.

Sha (2005-04-29 14:05:00) [23]
> Суслик © (29.04.05 12:35) [113]

>> В любой файловой системе переименование файла - атомарная
>> операция.

> верю :) Это документировано?

А ты можешь представить себе наполовину переименованный файл? :)

Суслик (2005-04-29 12:35:00) [24]

> В любой файловой системе переименование файла - атомарная
> операция.

верю :) Это документировано?

> [112] mgcr © (28.04.05 10:20)

хватит колкости говорить, я и тебя и Сашу слушаю, и не сомневаюсь в вашем уме.

mgcr (2005-04-28 10:20:00) [25]
Суслик © (27.04.05 01:11) [110]

> Я думаю, что лечше всего полагаться ни минимизирование (а
> не исключение) вероятности ошибки.

Лучше каждый оператор с молитвой писать. Оно надежнее. А еще лучше - послушать или почитать умных людей. Они тебе вреда не хотят.

Sha (2005-04-27 09:36:00) [26]
> Суслик © (27.04.05 01:11) [110]

В любой файловой системе переименование файла - атомарная операция.

Суслик (2005-04-27 01:11:00) [27]

> Sha © (26.04.05 21:23) [109]

При всем уважении, Саша, ты не писал систему - фиг ее знает, что тут атомарная операция, а что нет.

Я думаю, что лечше всего полагаться ни минимизирование (а не исключение) вероятности ошибки.

Sha (2005-04-26 21:23:00) [28]
> Суслик © (26.04.05 20:10) [108]
> Наверно лучше всего копировать файл, а не переименовывать.

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

Суслик (2005-04-26 20:10:00) [29]

> - переименовывать что-то.tmp в что-то.dat.

ой боюсь я за эту операцию :)))

Суслик (2005-04-26 20:10:00) [30]
правда она и у меня есть... так что может так и сделаю. Наверно лучше всего копировать файл, а не переименовывать. В этом случае вообще очень все надежно будет.

Sha (2005-04-26 19:46:00) [31]
> Суслик
> имеет право на жизнь?

Вроде имеет :)

Но получше будет так:
- писать что-то.tmp,
- удалять что-то.dat,
- переименовывать что-то.tmp в что-то.dat.
В этом случае время жизни "неправильного" имени меньше.

Суслик (2005-04-26 19:25:00) [32]

> [104] Суслик © (26.04.05 19:24)

Вернее не гаратированно не записал, а гарантированно не потерял.

Суслик (2005-04-26 19:24:00) [33]

> [103] Sha © (26.04.05 19:14)

т.е. отслюда следует вывод, что если я после возвратаиз flushFileBuffers удалю копию файла, то я гарантированно данные записал. Так?

Т.е. моя методика, описанная выше:
1.Переименовываю файл "что-то.dat" в "что-то.old"
2.Пишу в "что-то.dat"
3.Делаю flushFileBuffers для "что-то.dat"
4.Потом удалаю "что-то.old"
5.Если при загрузке системы есть "что-то.old", то был сбой. Тогда в качество "что-то.dat" нужно взять "что-то.old".

имеет правод на жизнь?

Sha (2005-04-26 19:14:00) [34]
> Суслик © (26.04.05 18:54) [98]
Точнее так:
на мой взгляд, для локального файла возрат из FlushFileBuffers гарантирует, что данные и метаданные будут записаны на диск даже если питание будет отключено до вызова CloseHandle.

Sha (2005-04-26 19:05:00) [35]
>Sha © (26.04.05 18:19) [95]
Вообще-то приведенный код не позволяет сделать
никаких выводов, т.к. Far получает уведомления с опозданием.

А если попробовать использовать FindFirst, то sr.Size
будет один и тот же независимо от вызова/невызова FlushFileBuffers, т.к. метаданные тоже кешируются.
В синхронность остается только верить...

alpet (2005-04-26 19:02:00) [36]
Суслик © (26.04.05 18:54) [98]

Если управление вернулось из функции - питание еще наличествует и файл уже на диске (на худой конец в кэше hdd). Если не вернулось (питание пропало или кто-то нажал Reset) - файл не записался до конца, при этом на диске он будет выглядеть либо как пустой, либо вообще отсутствовать.

Кстати выявляется вопрос - на сигнал Reset HDD сбрасывает аппаратный буфер или же записывает его на диск.

Суслик (2005-04-26 18:57:00) [37]
В общем, ладно. Спасибо всем за участие к проблеме.
Завтра у меня будет тестовый комп с образами разных систем и разными файловыми системами. Потестирую методику:
1.Переименовывать файл "что-то.dat" в "что-то.old"
2.Писать в "что-то.dat"
3.Делать flushFileBuffers для "что-то.dat"
4.Потом удалять "что-то.old"
5.Если при загрузке системы есть "что-то.old", то был сбой.

Об успехах доложу:)

alpet (2005-04-26 18:55:00) [38]
mgcr © (26.04.05 18:47) [97]
Ну стихийные бедствия я думаю нельзя предотвратить. Да и вирусов в порядке вещей повреждающих файлы мало. Так что с учетом отсутствия этих факторов, копии не нужны.

<offtop>
А какая тема - рекордсмен по количеству постов.

Суслик (2005-04-26 18:54:00) [39]

> [95] Sha © (26.04.05 18:19)

Таки что это доказывает?
Маленькое уточняющее резюме - ты считаешь, что функция flushFileBuffers будучи вызванной гарантирует, что файл будет записан даже если питание будет отключено? Запустался я что-то в высказываниях (((

> [97] mgcr © (26.04.05 18:47)
> Задача не стоит того флейма.

Предлагаю автору топика решать, что стоит его задача.

mgcr (2005-04-26 18:47:00) [40]
alpet © (26.04.05 18:32) [96]

А еще может случиться пожар и наводнение. Одновременно. Задача не стоит того флейма.

Страницы: < 1 2 3 4 5 6 7 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »