история
Во времена MS-DOS и PC-DOS утилита chkdsk
, когда она восстанавливала потерянные файлы (то есть файлы, в которых еще есть место, выделенное для них в FAT, но которых не было ни в одном каталоге), создавала записи каталога. для них в корневом каталоге с именем FILE
nnnn .CHK
и DIR
НННН .CHK
. В то время программа fsck
в Unices, напротив, помещала такие потерянные файлы, которые она нашла, в подкаталог корневого каталога lost+found
.
Эта стратегия chkdsk
была плохой по нескольким причинам, не в последнюю очередь из-за того, что на томах FAT12 и FAT16 корневой каталог имеет фиксированный размер и не имеет переменной длины, как другие каталоги. Если бы было слишком много потерянных файлов, chkdsk
закончил бы заполнением корневого каталога. Так что пришло время, когда IBM и Microsoft выпустили HPFS, которая была в OS/2 версии 1.2, было внесено изменение, так как для обеспечения поддержки HPFS требовалась оптовая модернизация таких инструментов, как chkdsk
, format
, sys
и recover
любом случае.
Таким образом, версия chkdsk
OS/2 была реализована так, чтобы делать то, что делал fsck
. Он создал подкаталоги в корневом каталоге и поместил туда новые записи каталога для восстановленных файлов. Он не использовал фиксированное имя подкаталога, как fsck
. Вместо этого он попытался создать found.
Каталог nnn , где nnn начинается с 000
и увеличивается до тех пор, пока не столкнется с каким-либо существующим подкаталогом. В этом каталоге будет весь FILE
nnnn .CHK
и DIR
НННН .CHK
файлы. Все еще возможно заполнить корневой каталог (в любом случае на FAT12 и FAT16 - HPFS не имеет корневых каталогов фиксированного размера), просто для этого требуется патологический сценарий того, кто сильно повреждает файловую систему и никогда не извлекает восстановленные файлы и каталоги вне каталога восстановления.
(fsck
использует фиксированный единственный подкаталог, потому что многие форматы файловых систем Unix имеют таблицы inode фиксированного размера. Напротив, HPFS и NTFS не имеют таблиц фиксированного размера для хранения f-узлов и записей MFT, и FAT даже не имеет таких вещей в первую очередь. Когда у каждого есть таблица фиксированного размера, он может потенциально столкнуться с ситуацией, когда нет свободных i-узлов, доступных для использования в качестве нового подкаталога восстановления, но у одного есть потерянные i-узлы для восстановления. fsck
избегает этой тупиковой ситуации, требуя для правильной работы, чтобы системный администратор создал lost+found
заранее, и всегда когда-либо использовал один и тот же каталог каждый раз. Конечно, это создаст lost+found
если он не существует, но это открывает дверь для вышеупомянутого тупика.)
Многие "команды DOS объяснили" WWW-сайты не скажут вам этого о chkdsk
, даже если он работал таким образом в операционной системе, которую вы и большинство людей используете уже два десятилетия. Вместо этого они все еще расскажут вам, как работал старый MS-DOS chkdsk
. Версия 1.2 OS/2 вышла в 1989 году. Windows NT, чья первая версия была в 1993 году, унаследовала несколько вещей от OS/2 1.x, включая это поведение chkdsk
. В то же время мир DOS и DOS+Windows весело продолжал в течение следующего десятилетия, не замечая - или никогда не включая - эти улучшения chkdsk
с конца 1980-х годов. Мир DOS и DOS+Windows, а также все книги и сайты WWW, появившиеся, чтобы рассказать о том, как они работали, фактически застряли в 1985 году. Однако мир DOS и DOS+Windows наконец-то умер своей заслуженной смертью, Windows NT не DOS и никогда не была, и команда chkdsk
в Windows NT перестала быть такой же, как команда DOS chkdsk
в конце 1980-х годов. , Поведение команды - это не то поведение, о котором вам скажут те люди, которые ошибочно думают, что это "команда DOS".
Обоснование и действие
Одна из причин того, что fsck
работает так, как он работает, заключается в том, что он был разработан для операционной системы, которая уже была многопользовательской в 1980-х годах. В защищенной многопользовательской операционной системе проблема безопасности возникает, если восстановление файлов после сбоя диска означает, что каждый может получить к ним доступ там, где раньше не мог. Таким образом, вы обнаружите, что стандартные разрешения для lost+found
в любой системе Unix или Linux, равны 0700 (rwx------
) с владельцем root
. Только суперпользователь может получить доступ к содержимому каталога. Таким образом, если файл ранее не находился в каталоге, доступном для группы / доступном миру, он внезапно не станет доступным для людей в результате восстановления после повреждения файловой системы.
chkdsk
в Windows NT сталкивается с теми же проблемами, поэтому вы обнаружите, что found.
Каталоги nnn доступны только администратору на томах NTFS. (На томах FAT списки ACL для файловых систем отсутствуют, поэтому защитить их таким способом невозможно. Тем не менее, файлы в их исходных местах не были обеспечены либо; так что это не вводит дыру в безопасности.) По этой же причине вы обнаружите, что каталог, лежащий в основе корзины на томах NTFS, структурирован как есть. Удаление файлов не делает их внезапно доступными для других людей, которые не имели бы к ним доступа в своих исходных каталогах.
Когда дело доходит до имен в верхнем уровне found.
nnn каталоги:
- По своей природе восстановленные потерянные файлы и каталоги не имеют имен на томах FAT. Имена были бы в записях каталога, указывающих на файлы, но файлы / каталоги не имели записей каталога, указывающих на них. Вот почему
FILE
nnnn .CHK
и DIR
НННН .CHK
имена используются. Имена должны быть придуманы для файлов и каталогов.
- На томах HPFS можно восстановить имя потерянного файла, поскольку он хранится в f-узле, а также в записи каталога, указывающей на f-узел. Но вы все равно найдете
FILE
nnnn .CHK
и DIR
НННН .CHK
имена используются.
- На томах NTFS обычно вообще не обнаруживаются потерянные файлы, восстановленные таким образом, поскольку запись MFT содержит имена файлов / каталогов и номера записей MFT изначально содержащих каталогов. Таким образом, восстановление потерянных файлов и каталогов в NTFS может фактически поместить их обратно в каталоги, из которых они были потеряны, и обычно (но не всегда) даже не нужно
found.
каталог nnn вообще. (Разумеется, если исходный файл не может быть восстановлен для размещения файла, конечно.) Вот почему редко можно увидеть found.
Каталоги nnn на томах NTFS по сравнению с томами FAT.
Конечно, имена файлов и каталогов в восстановленном каталоге будут сохранены, так как они не были потеряны в первую очередь. Скорее, это были записи в каталоге, который сам был потерян. Так что все ниже DIR
nnnn .CHK
на верхнем уровне будет иметь свое первоначальное имя.
На томах HPFS потерянный файл / каталог - это (выделенный) f-узел, в котором нет записи каталога, указывающей на него. На томах NTFS потерянный файл / каталог - это (выделенная) запись MFT, в которой нет записи каталога, указывающей на него. В обоих случаях все пространство, выделенное для файла / каталога, записывается в записи f-узла / MFT, и любые конфликты с битовой картой выделения тома разрешаются в пользу выделения пространства записи f-узла / MFT. На FAT все иначе. Здесь нет f-узлов, i-узлов или записей MFT. Единственный способ найти потерянные файлы / каталоги - это искать в FAT цепочки кластеров, на которые нет указателей, и FAT также является картой распределения. Таким образом, невозможно обнаружить разницу между действительно потерянным файлом / каталогом и фрагментом файла / каталога, который просто не был помечен как свободный на карте распределения томов. Так часто в FAT обнаруживается, что восстановленные файлы или каталоги являются частичными файлами или каталогами. (Это не означает, что невозможно получить частичные файлы / каталоги в HPFS и NTFS. Просто необходимые обстоятельства для этого встречаются гораздо реже, и в NTFS их практически полностью избегают за счет журналирования метаданных.)
Опять же, в HPFS и NTFS можно определить по записи f-узла /MFT, является ли восстановленный узел / запись файлом или каталогом. В записи f-узла /MFT есть флаг, говорящий, что это такое. Это не так с FAT. В лучшем случае можно применить эвристику, чтобы посмотреть на содержимое кластеров и угадать, что это была за штука. Так что иногда, если содержимое выглядит правильно, потерянный каталог может быть восстановлен в виде файла, и наоборот.
Последнее замечание: существует третий тип восстановленных файлов на томах FAT: EA
nnnn .CHK
. Это еще одно нововведение OS/2 1.x, которое появилось в Windows NT. Эти файлы содержат потерянные расширенные атрибуты . Наборы расширенных атрибутов хранятся в специальном файле контейнера (EA
DATA.
SF
) на томах FAT. Если ни одна запись каталога не указывает на определенный набор расширенных атрибутов, этот набор экспертов считается потерянным, и любой из них восстанавливается как EA
nnnn .CHK
или просто помечен как свободное место.