Есть необходимость преобразования большого числа файлов,
для чего пишется программа. Желательно, чтобы при сбое типа
отказа питания состояние файлов было узнаваемым. Насколько
допустимо в цикле делать так:

1. Создание файла A (пустого).
2. Действия A (Запись в файлы, сброс буферов).
3. Создание файла B (пустого).
4. Действия B1 (Запись в файлы, сброс буферов).
5. Удаление файла A.
6. Действия B2 (Запись в файлы, сброс буферов).
7. Удаление файла B.

Можно ли утверждать, что если файлов A и B нет, то результаты всех
выполненных действий записаны на диск. И вообще, по наличию/отсутствию
файлов A и B определить последнее успешное действие.

Спасибо.

Насчет смысла - я еще не решил, стоит ли городить этот огород, но затраты на него в данном случае невелики по сравнению с основной работой (результаты недоделанного действия A уничтожаются, B1 и B2 - запись информации о результатах A в два одинаковых файла). Ситуацию, когда выключался централизованный упс видел.
Насколько я понимаю, NTFS защищена только от повреждения собственной структуры, т.е. операции создания/удаления/распределения места журналируются, остальные - нет.

CreateFileTransacted к сожалению не подойдет. Ибо XP.

И более точный вопрос. Все же верно ли (X - файл X существует, в начале работы файлов естенственно нет)

!A && !B => Аварийных ситуаций не происходило
A && !B => точка 1 пройдена, точка 3 - нет, результат действия A непредсказуем
A && B => точка 3 пройдена, точка 5 - нет, результат действия A корректен, результат действия B1 непредсказуем
!A && B => точка 5 пройдена, точка 7 - нет, результат действий A и B1 корректен, результат действия B2 непредсказуем

ИМХО это может быть неверным только если возможно переупорядочивание действий системой.

Довольно старая статья http://www.ixbt.com/storage/ntfs2.html и в ней перечислены допущения относительно свойств дисков
Жесткий диск, в штатном режиме, должен записать именно то и именно туда, что и куда ему сказано было записать операционной системой. Данный принцип нарушается в случае, если система имеет ненадежный шлейф, процессор, память или контроллер - и это самая распространенная причина сбоев NTFS. Вам поможет: неразогнанный процессор, дорогая (качественная) память, хорошая материнская плата и протокол UDMA, обеспечивающий контроль и восстановление ошибок на участке контроллер-диск.

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

Диск обязан мгновенно осуществить запись данных, отправленных с флагом "не кэшировать". Дело в том, что многие современные диски или контроллеры обеспечивают задержанную запись. Метафайлы NTFS обновляются в режиме "писать сразу", и контроллер/диск обязан выполнять это требование.

Жесткий диск обязан обеспечить чтение именно тех данных, которые были записаны. В случае невозможности прочесть данные выдается сигнал "ошибка". Диск не имеет права возвращать ошибочные данные (возможно, лишь частично некорректные) без сигнала об ошибке. Все современные жесткие диски имеют контрольные суммы секторов и жестко следуют этой логике поведения.

2 Khod
Но тогда как ОС может гарантировать сохранность структуры ФС?
И как СУБД обеспечивают немедленную запись в журнальные файлы?

2 Akina

Полагаю, что это сложнее. Мне не нужно смотреть журналы, нужно чтобы при рестарте все было приведено в порядок автоматически.

По поводу журнала тот же вопрос о надежности.

2 Anatoly Podgoretsky

Какой алгоритм предлагается? Записывать все в БД? Это вариант (тем более, что в итоге все равно все должно попасть в БД) и он не был рассмотрен из-за большого желания (не моего) использовать для загрузки SQL*Loader.