[Allregia 9]

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

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

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

 

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

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

[AlexRayne 7]

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

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

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

 

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

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

 

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

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

 

 

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

 

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

 

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

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

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

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

[adnega 11]

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

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

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

[CrimsonPig 0]

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

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

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

 

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

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

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

 

[megajohn 8]

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

 

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

 

[HardEgor 89]

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

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

[jcxz 243]

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

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

 

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

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

[Гость TSerg]

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

[Allregia 9]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

[Ruslan1 17]

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

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

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

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

 

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

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

[Allregia 9]

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

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

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

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

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

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

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

[adnega 11]

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

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

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

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

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

 

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

[Allregia 9]

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

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

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

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

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

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

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

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

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

[adnega 11]

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

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

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

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

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

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

[jcxz 243]

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

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

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

 

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