Перейти к содержанию
    

Кто еще хорошо помнит как устроен FAT?

Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький.

Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы?

Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

 

Правда, если файл сначала удалят, а потом на его место запишут другой, то тогда он уже не попадет на те-же сектора?

А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький.

Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы?

Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

 

Правда, если файл сначала удалят, а потом на его место запишут другой, то тогда он уже не попадет на те-же сектора?

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

 

Насколько я понимаю вы пытаетесь както защитить файл, к которому стучитесь по кластерам, от перемещения по диску. Максимум на что можно расчитывать - что атрибут системный+скрытый+чтение файловые менеджеры с которыми будут иметь дело ваши пользователи учтут. по факту это так. (например в макОС атрибут "скрытый" требует довольно нетривиальных действий чтобы увидеть диск, хотя только в их родном финдере). Тотал командер и подобные лишний раз выдадут предупреждение прежде чем менять файл.

вобщем никаких гарантий закрепления файла Вы не имеете. и это вобщем относится к любой ФС, не надо стучаться к файлу физичеким кластерам.

 

 

А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?

 

Да это сработает.

 

Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

Проще отказаться от такого сомнительного требования и сделать все правильно.

Мучить одни и те же сектора не для всех носителей хорошая идея.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький.

Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы?

Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

 

Никто ничего не гарантирует. Все зависит от того, как конкретная имплементация файловой системы обращается с секторами, ищет свободные елементы в FAT итп.

Какой-нибудь сумасшедшей имплементации ничто не мешает аллоцировать кластера для файла в обратном порядке, например. И это будет абсолютно

валидно с т.з целостности файловой системы.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?

 

Выскажу глупое предложение, проверить вживую на FatFS

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?

Проще наверное сделать раздел размером с этот файл.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Проще наверное сделать раздел размером с этот файл.

Проще тогда не использовать ФС.

 

Выскажу глупое предложение, проверить вживую на FatFS

Выскажу неглупое предположение, что раз так поставлена задача - обойти ФС, то очевидно она вообще не нужна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да это сработает.

Ну, по видимому этого будет достаточно.

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

У меня нет библиотеки ФАТ, с ней не я работаю а извне.

Проще отказаться от такого сомнительного требования и сделать все правильно.

Мучить одни и те же сектора не для всех носителей хорошая идея.

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

Никто ничего не гарантирует. Все зависит от того, как конкретная имплементация файловой системы обращается с секторами,

В 99/999% случаев - это будет Винда.

Проще наверное сделать раздел размером с этот файл

Именно так и было сделано, пока файл был один.

Вопросы возникли, когда понадобилось кроме одного большого файла, иметь еще маленький, размером в несколько секторов/кластеров (в данном случае он у меня совпадают, по 512 байт).

Эти два файла занимают все место на диске, точнее - диск выглядит размером с суммарный размер обоих файлов.

Проще тогда не использовать ФС.

Осталось только обяснить это компу :)

 

Я не описывал подробностей, т.к. недумал что это имеет значение к вопросам исключительно по FAT, но видимо придется - файлы расположены на USB MSD девайсе, подключаемому к компу, поэтому всей работой с файловой системой занимается винда (ну может один из тысячи и будет использовать что-то другое), а девай только предоставляет различные области памяти для Boot, RootDirectory, FAT12. и собственно, содержимому файлов.

Для одного большого файла оно давно и успешно применяется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не описывал подробностей, т.к. недумал что это имеет значение к вопросам исключительно по FAT, но видимо придется - файлы расположены на USB MSD девайсе, подключаемому к компу, поэтому всей работой с файловой системой занимается винда (ну может один из тысячи и будет использовать что-то другое), а девай только предоставляет различные области памяти для Boot, RootDirectory, FAT12. и собственно, содержимому файлов.

Я не понял, почему нельзя сделать в данном случае просто полную совместимость снаружи с FAT, зачем какие-то ограничения?

просто перекодируете внешние запросы фата к секторам в запросы к памяти и все. Задача классическая и решение много где описано- эмуляция фата на флеше.

У майкрочипа есть отличный аппноут, ищите по "Microchip Memory Disk Drive File System", я когда-то его как основу использовал для похожей задачи: кусок памяти прикидывался маленькой юсб флешкой с FAT12. Доступ к Boot и Root у меня вообще в микроконтроллер обрабатывал (реально таких секторов не хранил, память экономил), а остальное- в изменяемой флешке.

 

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

Или вообще не используйте FAT, или делайте все правильно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

или делайте все правильно.

"Правильно" - это как?

Я не понял, почему нельзя сделать в данном случае просто полную совместимость снаружи с FAT, зачем какие-то ограничения?

Так и сделано - снаружи полная соввметимость.

просто перекодируете внешние запросы фата к секторам в запросы к памяти и все.

Это и сделано - ФАТ ссылается на сектора в памяти. Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам.

Микрочиповскую аппноту я знаю, но не очень понял причем тут она - в ней как использовать память как диск, это совсем другое и у них там нет задачи размещать файлы по конкретным адресам в памяти.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам.

Зачем? Вам же говорят забейте на сектора! Вы знаете таблицу FAT и при обращении к сектору вы можете понять смещение в файле.

Зная смещение, выдавайте порцию данных, которая этому смещению соответствует. Данные вообще могут быть не в секторах, а генерироваться на лету.

Компу с Виндой тоже будет легче, т.к. запись в файл стандартными средствами позволит вам задавать только смещение в файле

без необходимости указывать физические сектора.

 

Кста: вы же таблицу FAT можете генерить на лету, а не где-то хранить. Можно при каждом новом подключении генерить эту таблицу так, чтобы фрагментации не было вообще.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Зачем? Вам же говорят забейте на сектора! Вы знаете таблицу FAT и при обращении к сектору вы можете понять смещение в файле.

Именно так и делается.

Зная смещение, выдавайте порцию данных, которая этому смещению соответствует. Данные вообще могут быть не в секторах, а генерироваться на лету.

Компу с Виндой тоже будет легче, т.к. запись в файл стандартными средствами позволит вам задавать только смещение в файле

без необходимости указывать физические сектора.

Кста: вы же таблицу FAT можете генерить на лету, а не где-то хранить. Можно при каждом новом подключении генерить эту таблицу так, чтобы фрагментации не было вообще.

Таблица ФАТ и RootDir и генерируются каждый раз при включении, конечно без фрагментации.

В общем, проблема может быть только если сначала удалили оба файла, а потом записали первый маленький и затем большой - тогда маленьккий попадет в начало а большой за ним, изначально оно наоборот.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В общем, проблема может быть только если сначала удалили оба файла, а потом записали первый маленький и затем большой - тогда маленьккий попадет в начало а большой за ним, изначально оно наоборот.

Т.е. если файлов нет, Винда начинает писать какие-то сектора данных, и вы ничего не знаете о назначении этих данных.

Затем идет запись в таблицу FAT, и задним числом мы догадываемся, что запись данных относилась к тому или иному файлу.

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

что у вас не будет актуальной информации к какому файлу какие данные относятся. Причем, очень долго.

В этом проблема? Как это побороть стандартными средствами? Как устройство может запросить слив всех буферов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

 

Если на стороне винды пишет Ваше ПО, то в винде насколько помню есть функции позволяющие сделать некешируемую запись на диск (или сбросить кеш записи). Но опять-же - никто не гарантирует как драйвер ФС винды преобразует смещения в файле в кластера FAT.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...