Мое почтение всем. Нашел на сайте MS доку по FAT*, почти дочитал, и есть вопросы, по которым хочется получить уточнение. 1. Что считать признаком конца файла. По этому поводу пишут: Во-первых, не совсем ясно, почему файл, имеющий размер 0 может состоять из нескольких кластеров? Или это очередная опечатка? Во-вторых, получается, что значений метки "конец цепочки" несколько? Я поэкспериментировал на FAT12 (другого пока нет), получается, что если файл имеет размер 0, то для него конец цепочки будет 0xFF0, если же он имеет размер, или если это каталог (пусть даже нулевого размера), то конец цепочки будет иметь значение 0xFFF, 0xFFFF, etc, как и написано в доке. Мне это кажется немного странным, поэтому решил уточнить. Кстати, если все верно, то приведенный ими код для дискеты работать не будет. 2. Почему-то в доке ничего не сказано о том, как в FAT защищается кластер, ссылка на которые есть в entry файла в каталоге. Т.е. фактически на кластер тогда есть 2 ссылки -- в FAT и в каталоге. Для FAT12 в такую запись в FAT проставляется метка конца файла. Но т.к. в доке ничего не сказано и проверить нет пока возможности -- хочу уточнить. На всякий случай привожу оригинал цитаты. М.б. ошибся переводя? Заранее благодарен .
А где там сказано, что он имеет несколько кластеров? В записях каталога хранится номер первого кластера файла. В самой таблице ФАТ элемент с таким номером (индексом) содержит значение, обозначающее конец цепочки кластеров, т.е. фактически ни одного кластера файлу не выделяется. Хотя, в принципе, вручную можно создать файл нулевого размера и выделить ему несколько кластеров (создать всю цепочку вручную).
Mika0x65 Для уточнения - какой документ ты читаешь? Судя по всему: "Microsoft Extensible Firmware Initiative FAT32 File System Specification FAT: General Overview of On-Disk Format" Я буду давать страницы по v.1.03. Если у тебя другая, то могут быть некоторые отличия. Возможно, это просто неудачно сформулированная фраза, а цитированный тобой фрагмент просто имел в виду, что любая (кроме первых двух!!!) из записей FAT может содержать ссылку на следующий кластер или символ "конец цепочки". Но "нулевая запись FAT", номер которой "поставлен" у пустого файла, не может содержать ссылку не следующий кластер. Первые две записи в FAT зарезервированы. См. стр.18 (это немного дальше цитированного тобой фрагмента): What are the two reserved clusters at the start of the FAT for? The first reserved cluster, FAT[0], contains the BPB_Media byte value in its low 8 bits, and all other bits are set to 1. For example, if the BPB_Media value is 0xF8, for FAT12 FAT[0] = 0x0FF8, for FAT16 FAT[0] = 0xFFF8, and for FAT32 FAT[0] = 0x0FFFFFF8. The second reserved cluster, FAT[1], is set by FORMAT to the EOC mark. On FAT12 volumes, it is not used and is simply always contains an EOC mark. For FAT16 and FAT32, the file system driver may use the high two bits of the FAT[1] entry for dirty volume flags (all other bits, are always left set to 1). Note that the bit location is different for FAT16 and FAT32, because they are the high 2 bits of the entry. Слово "поставлен" я выделил кавычками именно потому, что нулевая запись _не может_ быть частью цепочки! "... the first data cluster is 2 and not 0 or 1"! Такое значение "первого кластера" должно обрабатываться отдельно, без просмотра цепочки. Теперь по поводу, BPB_Media. Он описан в таблице "Boot Sector and BPB Structure" стр.9-10. 0xF8 is the standard value for “fixed” (non-removable) media. For removable media, 0xF0 is frequently used. The legal values for this field are 0xF0, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE, and 0xFF. The only other important point is that whatever value is put in here must also be put in the low byte of the FAT[0] entry. This dates back to the old MS-DOS 1.x media determination noted earlier and is no longer usually used for anything. Как видишь, во-первых, всегда в этих записях (0й и 1й) значения - это либо знак "конец цепочки" (EOC), либо значение 0xF0. У тебя FAT12, вот и получается, что "файл имеет размер 0, то для него конец цепочки будет 0xFF0". Ты смотришь нулевую запись FAT, которая НИКОГДА не может быть частью "кластерной цепочки". Не очень понял, о какой защите ты говоришь, но я так понимаю, что такой защиты нет. В _норме_ на кластер не могут быть две ссылки. ТОЛЬКО либо из записи каталога, если это первый кластер цепочки, либо из записи другой цепочки. Во остальных случаях возникают ошибки, которые SCANDISK обозначает как "cross-linked files". Понятно, что чтение таких файлов приводит к получению неверных данных.
Так я понял, что "Note that a zero-length file—a file that has no data allocated to it—has a first cluster number of 0 placed in its directory entry. This cluster location in the FAT contains either an EOC mark or the cluster number of the next cluster of the file." об этом и говорит. Т.е. с одной стороны понятно, что такому файлу кластера не достанется, но с другой стороны -- может какой подвох есть .
Sergey_R Да, читаю именно его. Ясно, просто меня смутило, что для обозначения конца цепочки фактически используется 2 значения. В итоге получается, что сначала надо проверить, не содержит ли ссылка на начало цепочки 0, а потом уже бежать до EOC (т.е. проверять на равенство со 2ой записью в FAT). Ведь значение 0xFF0 как номера кластера остается валидным, если смотреть на пример кода? Насчет "защиты" я неверно выразился. Например, в каталоге отмечено, что цепочка начинается с 5ого кластера. Какое значение должно стоять в FAT в 5ой записи? В доке этого нет, проверил на FAT12 -- стоит EOC. Я так понимаю, EOC должно стоять и в FAT16, 32?
Для FAT12: FAT - массив 12-битных элементов. 0-й элемент содержит тип посителя. 1-й элемент содержит специальную сигнатуру EOC (варьируется от 0FF8h до 0FFFh (windows форматирует с 0FFFh)). Остальные элементы FAT содержат: 1. Либо значение определяющее номер кластера и одновременно индекс следующего элемента FAT. 1. Либо сигнатуру EOC, означающую, что предыдущий кластер был последним.
Mika0x65 Фактически :о) их используется 8(!) значений - от 0xF..F8 до 0xF..FFF. Значение же 0xFF0 действительно может быть нормальным номером кластера. Нет не нужно. Нужно всего лишь проверить, не равен ли нулю номер первого кластера из каталожной записи файла. Если равен, то размер файла нулевой (так как "нулевая запись" FAT _не_ используется), иначе начинай "разматывать" цепочку кластеров. Все зависит от размера файла. Если файл, занимающий 5й кластер целиком умещается в нем, то там будет стоять EOC. Если же нет, то там будет номер следующего кластера цепочки. И так до конца...
st.mmoning Это либо номер (или индекс, как угодно) следующего кластера, содержащего продолжение файла (и, соответственно, следующей записи FAT, которую нужно проверить), либо значение EOC, означающее, что ДАННЫЙ кластер (но не предыдущий!) был последним.
-->что ДАННЫЙ кластер (но не предыдущий!) был последним Да, имелось ввиду последний считанный. Кстати Кулаков в "Програмировании на аппаратном уровне" неверно считает нулевой элемент FAT сигнатурой, всегда равной 0FF8h. На практике же образ, считанный с дискеты содержит в данном элементе FAT - 0FF0h, что действительно соответствует "тип носителя=дискета". А 0FF8h, если не ошибаюсь, жесткий диск. "Значение же 0xFF0 действительно может быть нормальным номером кластера." Но только не для дискеты
0xF8 стандартное значение для "установленных" (не-сменных) средств. Для сменных средств, 0xF0 часто используется. PS: правда это относится к BPB_Media, но это стандартные константы для носителей.
Да, я это и имел ввиду . Пардон, ступил. Это же просто начало цепочки . Спасибо, пока вопрсоов больше нет .
