|
|
|
Кто еще хорошо помнит как устроен FAT? |
|
|
|
Oct 18 2016, 18:49
|
Профессионал
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763
|
Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький. Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы? Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?
Правда, если файл сначала удалят, а потом на его место запишут другой, то тогда он уже не попадет на те-же сектора? А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был?
|
|
|
|
|
Oct 19 2016, 06:54
|
Местный
Группа: Участник
Сообщений: 319
Регистрация: 27-09-07
Пользователь №: 30 877
|
Цитата(Allregia @ Oct 18 2016, 21:49) Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький. Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы? Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора?
Правда, если файл сначала удалят, а потом на его место запишут другой, то тогда он уже не попадет на те-же сектора? атрибут систем не гарантирует ничего - это некий атрибут "прав доступа" чтоли - что с фалом можно делать а что нельзя.он работает исключаительно как информация, и все АПИ работы с файлами атрибутов не учитывают. атрибуты даются пользователю исключительно. ну может быть вы встретите библиотеку которая их учитывает, но я такого не видел. Насколько я понимаю вы пытаетесь както защитить файл, к которому стучитесь по кластерам, от перемещения по диску. Максимум на что можно расчитывать - что атрибут системный+скрытый+чтение файловые менеджеры с которыми будут иметь дело ваши пользователи учтут. по факту это так. (например в макОС атрибут "скрытый" требует довольно нетривиальных действий чтобы увидеть диск, хотя только в их родном финдере). Тотал командер и подобные лишний раз выдадут предупреждение прежде чем менять файл. вобщем никаких гарантий закрепления файла Вы не имеете. и это вобщем относится к любой ФС, не надо стучаться к файлу физичеким кластерам. Цитата(Allregia @ Oct 18 2016, 21:49) А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был? Да это сработает. Цитата(Allregia @ Oct 18 2016, 21:49) Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора? зависит от реализации вашей библиотеки работы с фат. то что я встречал - если перезаписывать содержимое файла, то оно и перепиывается в тех кластерах в которых лежит. другое поведение сделать накладно, наверняка в вашей библиотеке так есть. если вы укоротите файл, и начнете дописывать в хвост - то по идее сначала освободятся кластеры, а потом надо будет переразмещать их заново. в этом случае никаких гарантий нет. где библиотека захочет - там и возьмет кластеры. Вы можете расчитыать на какуюто предсказуемость в системе монопольно владеющей томом, без конкурентного доступа.
|
|
|
|
|
Oct 19 2016, 08:09
|
Местный
Группа: Участник
Сообщений: 329
Регистрация: 23-04-14
Пользователь №: 81 502
|
Цитата(Allregia @ Oct 18 2016, 19:49) Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький. Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы? Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора? Никто ничего не гарантирует. Все зависит от того, как конкретная имплементация файловой системы обращается с секторами, ищет свободные елементы в FAT итп. Какой-нибудь сумасшедшей имплементации ничто не мешает аллоцировать кластера для файла в обратном порядке, например. И это будет абсолютно валидно с т.з целостности файловой системы.
|
|
|
|
|
Oct 19 2016, 09:32
|
Профессионал
Группа: Свой
Сообщений: 1 080
Регистрация: 16-11-04
Из: СПб
Пользователь №: 1 143
|
Цитата(Allregia @ Oct 18 2016, 21:49) А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был? Выскажу глупое предложение, проверить вживую на FatFS
--------------------
Марс - единственная планета, полностью населенная роботами (около 7 штук).
|
|
|
|
|
Oct 19 2016, 15:01
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(HardEgor @ Oct 19 2016, 13:22) Проще наверное сделать раздел размером с этот файл. Проще тогда не использовать ФС. Цитата(megajohn @ Oct 19 2016, 12:32) Выскажу глупое предложение, проверить вживую на FatFS Выскажу неглупое предположение, что раз так поставлена задача - обойти ФС, то очевидно она вообще не нужна.
|
|
|
|
Guest_TSerg_*
|
Oct 19 2016, 15:41
|
Guests
|
Делается контейнер, по примеру TrueCrypt и размером с файл и в нем файл будет в безопасности по местоположению.
|
|
|
|
|
Oct 19 2016, 18:30
|
Профессионал
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763
|
Цитата(AlexRayne @ Oct 19 2016, 07:54) Да это сработает. Ну, по видимому этого будет достаточно. Цитата зависит от реализации вашей библиотеки работы с фат. то что я встречал - если перезаписывать содержимое файла, то оно и перепиывается в тех кластерах в которых лежит. другое поведение сделать накладно, наверняка в вашей библиотеке так есть. У меня нет библиотеки ФАТ, с ней не я работаю а извне. Цитата Проще отказаться от такого сомнительного требования и сделать все правильно. Мучить одни и те же сектора не для всех носителей хорошая идея. Никто из мучать не будет, требования сохранения абсолютного местоположения - не обсуждаемо, иначе весь смысл теряется. Цитата Никто ничего не гарантирует. Все зависит от того, как конкретная имплементация файловой системы обращается с секторами, В 99/999% случаев - это будет Винда. Цитата Проще наверное сделать раздел размером с этот файл Именно так и было сделано, пока файл был один. Вопросы возникли, когда понадобилось кроме одного большого файла, иметь еще маленький, размером в несколько секторов/кластеров (в данном случае он у меня совпадают, по 512 байт). Эти два файла занимают все место на диске, точнее - диск выглядит размером с суммарный размер обоих файлов. Цитата Проще тогда не использовать ФС. Осталось только обяснить это компу Я не описывал подробностей, т.к. недумал что это имеет значение к вопросам исключительно по FAT, но видимо придется - файлы расположены на USB MSD девайсе, подключаемому к компу, поэтому всей работой с файловой системой занимается винда (ну может один из тысячи и будет использовать что-то другое), а девай только предоставляет различные области памяти для Boot, RootDirectory, FAT12. и собственно, содержимому файлов. Для одного большого файла оно давно и успешно применяется.
|
|
|
|
|
Oct 19 2016, 19:04
|
Гуру
Группа: Свой
Сообщений: 2 360
Регистрация: 6-03-06
Из: Кишинев
Пользователь №: 15 025
|
Цитата(Allregia @ Oct 19 2016, 20:30) Я не описывал подробностей, т.к. недумал что это имеет значение к вопросам исключительно по FAT, но видимо придется - файлы расположены на USB MSD девайсе, подключаемому к компу, поэтому всей работой с файловой системой занимается винда (ну может один из тысячи и будет использовать что-то другое), а девай только предоставляет различные области памяти для Boot, RootDirectory, FAT12. и собственно, содержимому файлов. Я не понял, почему нельзя сделать в данном случае просто полную совместимость снаружи с FAT, зачем какие-то ограничения? просто перекодируете внешние запросы фата к секторам в запросы к памяти и все. Задача классическая и решение много где описано- эмуляция фата на флеше. У майкрочипа есть отличный аппноут, ищите по "Microchip Memory Disk Drive File System", я когда-то его как основу использовал для похожей задачи: кусок памяти прикидывался маленькой юсб флешкой с FAT12. Доступ к Boot и Root у меня вообще в микроконтроллер обрабатывал (реально таких секторов не хранил, память экономил), а остальное- в изменяемой флешке. Обязательно нужно полностью поддерживать фат без всяких ограничений "что, куда, как и сколько писать" - эти ограничения будут жить до первого юзера и прибор придет в ремонт. Или же это случится из-за запуска формата-чекдиска-посекторного редактора- любая из этих софтин должна нормально работать с Вашей "флешкой". Или вообще не используйте FAT, или делайте все правильно.
|
|
|
|
|
Oct 19 2016, 21:20
|
Профессионал
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763
|
Цитата или делайте все правильно. "Правильно" - это как? Цитата Я не понял, почему нельзя сделать в данном случае просто полную совместимость снаружи с FAT, зачем какие-то ограничения? Так и сделано - снаружи полная соввметимость. Цитата просто перекодируете внешние запросы фата к секторам в запросы к памяти и все. Это и сделано - ФАТ ссылается на сектора в памяти. Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам. Микрочиповскую аппноту я знаю, но не очень понял причем тут она - в ней как использовать память как диск, это совсем другое и у них там нет задачи размещать файлы по конкретным адресам в памяти.
|
|
|
|
|
Oct 19 2016, 21:35
|
Гуру
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702
|
Цитата(Allregia @ Oct 20 2016, 00:20) Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам. Зачем? Вам же говорят забейте на сектора! Вы знаете таблицу FAT и при обращении к сектору вы можете понять смещение в файле. Зная смещение, выдавайте порцию данных, которая этому смещению соответствует. Данные вообще могут быть не в секторах, а генерироваться на лету. Компу с Виндой тоже будет легче, т.к. запись в файл стандартными средствами позволит вам задавать только смещение в файле без необходимости указывать физические сектора. Кста: вы же таблицу FAT можете генерить на лету, а не где-то хранить. Можно при каждом новом подключении генерить эту таблицу так, чтобы фрагментации не было вообще.
|
|
|
|
|
Oct 19 2016, 23:18
|
Профессионал
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763
|
Цитата(adnega @ Oct 19 2016, 22:35) Зачем? Вам же говорят забейте на сектора! Вы знаете таблицу FAT и при обращении к сектору вы можете понять смещение в файле. Именно так и делается. Цитата Зная смещение, выдавайте порцию данных, которая этому смещению соответствует. Данные вообще могут быть не в секторах, а генерироваться на лету. Компу с Виндой тоже будет легче, т.к. запись в файл стандартными средствами позволит вам задавать только смещение в файле без необходимости указывать физические сектора. Кста: вы же таблицу FAT можете генерить на лету, а не где-то хранить. Можно при каждом новом подключении генерить эту таблицу так, чтобы фрагментации не было вообще. Таблица ФАТ и RootDir и генерируются каждый раз при включении, конечно без фрагментации. В общем, проблема может быть только если сначала удалили оба файла, а потом записали первый маленький и затем большой - тогда маленьккий попадет в начало а большой за ним, изначально оно наоборот. Но ничего страшного не случится - надо будет просто переподключить устройство к компу и записать заново, уже в правильном порядке, или не удалять файлы а просто перезаписывать (т.е. копировать туда новый файл но с тем-же именем).
|
|
|
|
|
Oct 20 2016, 10:36
|
Гуру
Группа: Свой
Сообщений: 2 724
Регистрация: 14-05-07
Из: Ярославль, Россия
Пользователь №: 27 702
|
Цитата(Allregia @ Oct 20 2016, 02:18) В общем, проблема может быть только если сначала удалили оба файла, а потом записали первый маленький и затем большой - тогда маленьккий попадет в начало а большой за ним, изначально оно наоборот. Т.е. если файлов нет, Винда начинает писать какие-то сектора данных, и вы ничего не знаете о назначении этих данных. Затем идет запись в таблицу FAT, и задним числом мы догадываемся, что запись данных относилась к тому или иному файлу. Поскольку таблица FAT может кешироваться на стороне Винды, то любые манипуляции с размещением файлов приведут к тому, что у вас не будет актуальной информации к какому файлу какие данные относятся. Причем, очень долго. В этом проблема? Как это побороть стандартными средствами? Как устройство может запросить слив всех буферов?
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|