TerminateProcess

← →
Sha © (2005-04-29 16:25) [120]

Цитата из неизданного MS.

← →
alpet © (2005-04-29 16:33) [121]

Если свести изменение имени файла к физическому процессу - это передача в буфер данных для как минимум одного сектора из системной области (Root Directory?). Можно быть уверенным в атомарности этой операции, поскольку жесткий диск не начнет записи, пока все заявленные данные не будут переданны в его кэш. По исчезновении питания HDD наверняка успеет записать переданные данные в кэш (ему при наихудших раскладах на все надо примерно 1/8 секунды), если запись уже начата.

← →
Sha © (2005-04-29 16:39) [122]

> alpet © (29.04.05 16:33) [121]
> По исчезновении питания HDD наверняка успеет записать переданные данные в кэш

Обязан успеть, иначе данные на диске будут физически разрушены.
Т.е. либо не начнет, либо закончит.

← →
Суслик © (2005-04-29 16:42) [123]

> [122] Sha © (29.04.05 16:39)

я в полном ступоре. Ты с одной стороны цитируешь потенциальную опастность переименования, с другой - говоришь, что "обязан успеть". Я что-то не понимаю (

← →
Sha © (2005-04-29 16:49) [124]

Суслик © (29.04.05 16:42) [123]

Цитирую неизданное MS. Могу процитировать что-нибудь неизданное тобой, могу процитировать даже ненаписанное.
Чуть выше я говорил об атомарности переименования файла в прелелах каталога.
Вроде тут нет противоречия.

← →
Sha © (2005-04-29 17:22) [125]

> Суслик © (29.04.05 16:42) [123]

Физически изменения в каталоге при переименовании или удалении файла (8.3) сводятся к перезаписи одного сектора. Сектор нельзя записать наполовину.

В отношении цитат. Из ненаписанного тобой:
"Все файловые системы MS прекрасно описаны и абсолютно надежны.
Не существует проблем с пониманием логики их работы и восстановлением после сбоев".

← →
alpet © (2005-04-29 17:33) [126]

Что-бы окончательно успокоить - если каким-то чудом запись сектора прервется - данные с него прочесть попросту не удаться. Насколько я помню они апаратно защищены CRC - и при несовпадении контрольной суммы жесткий диск может вполне решить что сектор поврежден, и пометит его соответствующим образом (восстановить конечно можно будет его обычным форматированием). А система увидев такие повреждения в системной области ROOT, скорее всего пропавшие файлы (имен в секторе может быть несколько) обнаружит при проверке и назовет типа file001.chk. Так-что переименование можно считать операцией безопасной - либо будет файл с новым именем, либо не будет но это очень маловерятно.

← →
Sha © (2005-04-29 17:40) [127]

> alpet © (29.04.05 17:33) [126]
> Что-бы окончательно успокоить - если каким-то чудом запись
> сектора прервется - данные с него прочесть попросту не
> удаться. Насколько я помню они апаратно защищены CRC

Пропадание питания - штатная ситуация.
Есть мнение, что современные жесткие диски не только успевают
закончить незавершенные операции, но и увести головки в область
парковки.

← →
mgcr © (2005-04-29 20:32) [128]

Sha © (29.04.05 17:40) [127]

> что современные жесткие диски не только успевают
> закончить незавершенные операции, но и увести головки в
> область
> парковки.

Там эта...конденсатор стоит...Ну и в блоке питания тоже...Даже два...

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

Суслик © (29.04.05 16:42) [123]

А по поводу безопасности переименования, ты попробуй представить себе ситуацию пропадания питания во время операции переименования и все ее последствия. Даже не читая Руссиновича с братом его во Христе Соломоном. Просто для себя представь, что может произойти и сделай выводы.

← →
Alex Konshin © (2005-05-01 05:35) [129]

Sha © (29.04.05 17:22) [125]
> Суслик © (29.04.05 16:42) [123]
Физически изменения в каталоге при переименовании или удалении файла (8.3) сводятся к перезаписи одного сектора.

Ты неправ. Как минимум двух. Оглавление никогда не пишется по месту. А потому будет изменен по крайней мере еще один блок, который содержит ссылку на блок оглавления, и далее - рекурсивно к корню. Это будет как и в случае цепочечных, так и гиперблоковых FS.

← →
Sha © (2005-05-01 12:51) [130]

> Alex Konshin © (01.05.05 05:35) [129]

Общая идеология понятна.

Однако, нет уверенности, что разработчики не использовали
возможность оптимизации для имен формата 8.3, которые всегда
помещаются в одном блоке.

Не скажу точно, как на самом деле - очень давно рылся в
исходниках DOS.

← →
mgcr © (2005-05-01 17:37) [131]

Alex Konshin © (01.05.05 05:35) [129]
Sha © (01.05.05 12:51) [130]

Что будет при переименовании файла в FAT я не знаю, а вот в NTFS перепишется один блок MFT (размером в один килобайт) и занесется одна запись в журнал транзакций NTFS. Итого - несколько операций ввода вывода (одна отложенная - запись блока MFT)

Во всех FS, что я знаю запись измененного блока всегда идет на новое место. В NTFS наверняка тоже, т.к. во-первых, это правильно, во-вторых иначе не было бы возможности откатить транзакцию. Так как пишем в другое место, то обязательно будет изменен как минимум еще один блок, который указывает на измененый. Будет ли это гипреблок или блок в FAT (или как он называется в той FS) - неважно. Так как изменяется этот гиперблок, то также будет изменен гиперблок, указывающий на него, и так по рекурсии.
Вот именно об этом я и написал. Неужели это не очевидно?

> Alex Konshin © (02.05.05 05:17) [132]

Конкретный пример. Удаление файла 8.3 в MS-DOS.
Т.е. необходимо изменить 1 байт в 1 секторе оглавления.
Работу с FAT опускаем, или считаем что FileSize=0.

Ты абсолютно уверен, что здесь не будет перезаписи
блока оглавления по месту?

В DOS, насколько я помню, две FAT. Я не проверял, но не удивлюсь, если перезаписи по месту не будет. Иначе зачем две FAT? Скорее всего будет изменятся неактивная FAT и только потом она становится активной. Сколько это потребует операций записи можешь сам посчитать.
Вообще-то хрен его знает, в DOS вполне могла быть запись по месту. Но ни на NTFS, ни на FAT32 так не получится хотя бы потому, что там имена переменной длины. Но обратное неверно: из того, что имена фиксированной длины совсем не следует, что будет перезапись по месту, например, в той же файловой системе CMS имена фиксированной длины, но перезаписи по месту там точно не было, это я знаю на 100%. Так что для меня еще не факт, что в DOS было не так, хотя и допускаю - там экономили на чем только можно.

Работу с FAT опускаем, или считаем что FileSize=0.
Причем тут FileSize? Оглавление само по себе тоже файл, а у него уж всяко размер ненулевой. Изменение любого файла не по месту (и оглавления в том числе) приводит к изменению FAT. Зачастую в файловых системах и сам FAT (или его аналог) тоже выглядит как файл. В гиперблочных FS в роли недоразвитой FAT выступает битовая таблица занятости секторов вместе с гиперблоками файла-оглавления. Можно, правда, отвести для всего FAT фиксированную область на диске (или несколько), тогда сам FAT будет обновляться по месту (по-моему в DOS так - я уже не помню). Но с оглавлением такой фокус не пройдет - оно просто обязано быть обычным файлом.

> Alex Konshin © (03.05.05 05:07) [134]
> В DOS, насколько я помню, две FAT.

Это я знаю. Только причем зесь это?
Обрати пожалуйста внимание, я везде говорю только о количестве
операций с оглавлением, а FAT не трогаю. Делаю это намеренно,
чтобы нагляднее показать, что запись по месту при работе с
оглавлением возможна и выгодна.

> Вообще-то хрен его знает, в DOS вполне могла быть запись по месту.

Вот и я о том же. А если писать огавление по месту, то изменять FAT при переименовании, очевидно, не потребуется.

> Оглавление само по себе тоже файл, а у него уж всяко размер
> ненулевой. Изменение любого файла не по месту (и оглавления в
> том числе) приводит к изменению FAT.

Это понятно, но это не наш случай. Мы правим по месту.

> Можно, правда, отвести для всего FAT фиксированную область на
> диске (или несколько), тогда сам FAT будет обновляться по
> месту (по-моему в DOS так - я уже не помню).

Именно так.

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

Одно никак не следует из другого.
Во первых, сам так делал.
Во-вторых, как, по твоему, работали всевозможные FileRestore, NortonUtilities, восстанавливающие удаленные файлы. Да ты и сам мог сделать это при помощи DiskEditor"a, правя один сектор оглавления по месту (о FAT опять молчим).
А если можно обратно, то почему нельзя туда?

В общем, я думаю, не стоит учить друга, теорию мы оба знаем.

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

Всем спасибо, за ответы и разъяснения. Появилась достаточная информация для принятия решения о будущей архитектуре.

> А если интересно - он сам должен уметь находить нужную страниу.

я все умею, но на это нужно время. Поэтому решил воспользоваться форумом для личной экономии времени и не вижу в этом проблем. Да и топик такой содержательный и объемный получился, так это вообще хорошо - и форуму полезно:)

TerminateProcess Найти похожие ветки