При гибели трека 0 в реале действуют так. Запускают программку REPAIR.COM, чтобы заново отформатировать только резервированные (системные) треки, восстановив тем самым ИНФО-блок. После чего можно скопировать файлы на другой диск.
Если же первый сектор диска сдох насмерть, то нужна специальная программа форматирующая трек 0 хитрым способом. Это простенькая, но полезная программа, вариант форматёра, позволяющая "вернуть жизнь" дискетам с дохлым треком 0. Она сначала заново форматирует трек (т.к порядок следования секторов у разных форматёров разный, есть нумерация подряд, а есть формат с интерливингом), затем выясняет какой сектор нормально читается. А затем форматирует 0-й трек так, что сектор 1 оказывается как раз на том месте, где читался исправный сектор, а все остальные сектора форматируются с номером сектора 99. Тогда сектор 1, содержащий ИНФО-блок для настройки на формат, читается.
Естественно, такой диск уже не может стать загрузочным, т.е содержать систему на резервных треках. До появленния такой программы, чтобы считать диск с дохлым BOOT-сектором, я использовал версию CP/M вообще не имеющую автонастройки на формат диска, т.е читающую только в одном жёстко заданном в BIOS формате.
Для РК-ДОС, где каталог на 32-м треке, если этот трек каталога сдох, есть возможность всё-равно использовать такой диск. Тогда дискета форматируется не на 80 треков, а на 79 треков, причем треки 0 и 1 форматируются как трек 0, трек 2 как 1, 3 как 2, т.е сдвижка нумерации. Логические номера треков сдвигаются на 1 относительно физических номеров. В итоге трек 32, где каталог, оказывается на другой, уже исправной дорожке.
Ещё более сложную задачу приходится решать, когда сдох каталог, а вашим AUTOEXEC.SUB-ом при каждой загрузке не запускалась программка SVDIR.COM А.Новгородова (1992), автоматически делающая копию каталога в неиспользуемом (при DD) треке 3. Если каталог был резервирован, то достаточно запустить RSTDIR.COM, чтобы скопировать каталог из трека 3 в трек 4 и тогда, по крайней мере, те файлы, что не менялись можно считать.
В противном случае приходится действовать так. Загружаем DU.COM и с её помощью считываем целые сектора каталога (из 4-х секторов каталога всегда дохлый только один). Путём многкратных попыток считать дохлый трек каталога, наконец считываем его. Если это удалось, то Вам повезло. Если нет, то выходим в SHELL-монитор, и смотрим содержимое дискового буфера. Иногда там находится частично дохлый сектор каталога. Если не помогло, то используем только исправные сектора каталога. Три оставшихся целыми сектора каталога, переносим на трек 2 (не 3, надо чтобы смещение было кратно размеру блока). Теперь каталог перенесён на трек 2. Далее той-же программой DU заменяем в T0; S1; байт с офсетом 1D с 4 на 2 (число сист.треков) и на 2 уменьшаем КС в байте 1F. Вот почему выбрана арифметическая сумма, а не CRC или PARITY, - чтобы человеку было удобно "ковырять" БПД вручную.
Теперь диск читается, но номера блоков в экстентах каталога сдвинуты на 5 (в 2-х треках 10 кб, что при размере блока в 2К даёт 5). Надо иметь программу, которая считает все экстенты каталога и увеличит в них номера блоков на 5. Однако я так и не сделал такой программы, т.к обычно незаменимым и подлежащим восстановлению был только единственный файл исходника. А скорректировать каталоговые записи для одного файла легко с помощью DU. Запускаем поиск в диске по ASCII-цепочке с именем файла, находим каталоговые экстенты файла и к номерам блоков прибавляем 5. После чего копируем файл на другой диск, а эту дискету, чтобы не иметь в дальнейшем подобных проблем, форматируем в такой формат, где каталог уже не на треке 4, который дохнет.
Ещё более трудоёмко восстановление, если запись о Вашем нужном файле оказалась в сдохшем секторе каталога. Тогда форматируем каталог на треке 4, если не получилось то переносим каталог на трек 2 (заменой 2-х байтов в ИНФО-блоке). Т.к физически CP/M пишет блоками, то иногда в последнем секторе файла с размером не точно кратным 1 кб, оказывается содержимое каталога. Поэтому первым делом запускаем поиск в диске ASCII цепочки с именем файла. Если кусок каталога с записью о нужном файле будет найден, это еще не означает удачу, т.к номера блоков могут быть устарелыми. Надо переписать номера блоков и в восстановленном каталоге вручную с помощью DU создать экстент и занести номера блоков (прибавив 5, если каталог переносился на трек 2). Надо попытаться найти все экстенты файла отсканировав весь диск. Если это поможет найти блок начала файла, это уже удача, особенно если файл сильно дефрагментирован и работа над исходником длилась много дней, отчего на диске полно блоков, содержащих куски актуального файла, куски его предыдущих версий и файлы свопинга. Именно поэтому в начале исходника всегда надо писать дату и время (меняя время при каждой записи). Тогда удастся верно найти первый блок файла и все блоки до этого блока, где есть куски файла будем считать не актуальными.
Если номера блоков неизвестны, то остаётся визульно просматривать все сектора (с шагом в два физ.сектора, т.к CP/M пишет блоками) и отыскивать куски Вашего исходника. Неприятно то, что блок с вашим текстом не значит, что он из файла, а может быть из файла свопинга. Из-за этого, сохранив все найденные куски подряд, Вы обнаружите, что много кусков повторяется и порядок следования этих кусков неверный. В общем восстановление сильно фрагментированного файла, когда нет никаких данных из каталоговой записи - это каторжная работа.
Один раз мне пришлось восстанавливать исходник 60 кб, результат 2-х месячной работы и это заняло 16 часов тяжёлого труда и исходник получился неверным. Его пришлось долго доводить редактором до хотя бы транслируемого состояния, т.к он состоял из фрагментов от разных версий. Чтобы облегчить труд по восстановлению, нужен текстовый редактор не создающий файлов свопинга и BAK-файлов. Тогда фрагменты файла будут следовать подряд и их легко будет найти, чтобы восстановить файл в случае гибели каталога.
[свернуть]
