Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький.
Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы?
Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?

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

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

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




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


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

Проще отказаться от такого сомнительного требования и сделать все правильно.
Мучить одни и те же сектора не для всех носителей хорошая идея.

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

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

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

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


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

Делается контейнер, по примеру TrueCrypt и размером с файл и в нем файл будет в безопасности по местоположению.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Т.е. если файлов нет, Винда начинает писать какие-то сектора данных, и вы ничего не знаете о назначении этих данных.
Затем идет запись в таблицу FAT, и задним числом мы догадываемся, что запись данных относилась к тому или иному файлу.
Поскольку таблица FAT может кешироваться на стороне Винды, то любые манипуляции с размещением файлов приведут к тому,
что у вас не будет актуальной информации к какому файлу какие данные относятся. Причем, очень долго.
В этом проблема? Как это побороть стандартными средствами? Как устройство может запросить слив всех буферов?

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

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