Allregia 9 18 октября, 2016 Опубликовано 18 октября, 2016 · Жалоба Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький. Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы? Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора? Правда, если файл сначала удалят, а потом на его место запишут другой, то тогда он уже не попадет на те-же сектора? А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexRayne 7 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький. Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы? Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора? Правда, если файл сначала удалят, а потом на его место запишут другой, то тогда он уже не попадет на те-же сектора? атрибут систем не гарантирует ничего - это некий атрибут "прав доступа" чтоли - что с фалом можно делать а что нельзя.он работает исключаительно как информация, и все АПИ работы с файлами атрибутов не учитывают. атрибуты даются пользователю исключительно. ну может быть вы встретите библиотеку которая их учитывает, но я такого не видел. Насколько я понимаю вы пытаетесь както защитить файл, к которому стучитесь по кластерам, от перемещения по диску. Максимум на что можно расчитывать - что атрибут системный+скрытый+чтение файловые менеджеры с которыми будут иметь дело ваши пользователи учтут. по факту это так. (например в макОС атрибут "скрытый" требует довольно нетривиальных действий чтобы увидеть диск, хотя только в их родном финдере). Тотал командер и подобные лишний раз выдадут предупреждение прежде чем менять файл. вобщем никаких гарантий закрепления файла Вы не имеете. и это вобщем относится к любой ФС, не надо стучаться к файлу физичеким кластерам. А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был? Да это сработает. Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора? зависит от реализации вашей библиотеки работы с фат. то что я встречал - если перезаписывать содержимое файла, то оно и перепиывается в тех кластерах в которых лежит. другое поведение сделать накладно, наверняка в вашей библиотеке так есть. если вы укоротите файл, и начнете дописывать в хвост - то по идее сначала освободятся кластеры, а потом надо будет переразмещать их заново. в этом случае никаких гарантий нет. где библиотека захочет - там и возьмет кластеры. Вы можете расчитыать на какуюто предсказуемость в системе монопольно владеющей томом, без конкурентного доступа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора? Проще отказаться от такого сомнительного требования и сделать все правильно. Мучить одни и те же сектора не для всех носителей хорошая идея. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
CrimsonPig 0 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Вопрос можео несколько глуповатый - на диске с ФАТ 2 файла, большой и маленький. Если файлу поставить аттрибут "System", вроде так метятся неперемещаемые файлы? Гарантирует ли это, что при перезаписи файла он запишется в те-же сектора? Никто ничего не гарантирует. Все зависит от того, как конкретная имплементация файловой системы обращается с секторами, ищет свободные елементы в FAT итп. Какой-нибудь сумасшедшей имплементации ничто не мешает аллоцировать кластера для файла в обратном порядке, например. И это будет абсолютно валидно с т.з целостности файловой системы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
megajohn 5 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был? Выскажу глупое предложение, проверить вживую на FatFS Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HardEgor 76 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба А если я скорректирую бут-сектор, что так Root Entry=2, а в FAT вообще все незанятые кластеру пропишу как BAD, то если удалить только один файл, а потом писать снова, ему деваться некуда будет, только в те-же сектра где он был? Проще наверное сделать раздел размером с этот файл. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Проще наверное сделать раздел размером с этот файл. Проще тогда не использовать ФС. Выскажу глупое предложение, проверить вживую на FatFS Выскажу неглупое предположение, что раз так поставлена задача - обойти ФС, то очевидно она вообще не нужна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость TSerg 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Делается контейнер, по примеру TrueCrypt и размером с файл и в нем файл будет в безопасности по местоположению. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Allregia 9 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Да это сработает. Ну, по видимому этого будет достаточно. зависит от реализации вашей библиотеки работы с фат. то что я встречал - если перезаписывать содержимое файла, то оно и перепиывается в тех кластерах в которых лежит. другое поведение сделать накладно, наверняка в вашей библиотеке так есть. У меня нет библиотеки ФАТ, с ней не я работаю а извне. Проще отказаться от такого сомнительного требования и сделать все правильно. Мучить одни и те же сектора не для всех носителей хорошая идея. Никто из мучать не будет, требования сохранения абсолютного местоположения - не обсуждаемо, иначе весь смысл теряется. Никто ничего не гарантирует. Все зависит от того, как конкретная имплементация файловой системы обращается с секторами, В 99/999% случаев - это будет Винда. Проще наверное сделать раздел размером с этот файл Именно так и было сделано, пока файл был один. Вопросы возникли, когда понадобилось кроме одного большого файла, иметь еще маленький, размером в несколько секторов/кластеров (в данном случае он у меня совпадают, по 512 байт). Эти два файла занимают все место на диске, точнее - диск выглядит размером с суммарный размер обоих файлов. Проще тогда не использовать ФС. Осталось только обяснить это компу :) Я не описывал подробностей, т.к. недумал что это имеет значение к вопросам исключительно по FAT, но видимо придется - файлы расположены на USB MSD девайсе, подключаемому к компу, поэтому всей работой с файловой системой занимается винда (ну может один из тысячи и будет использовать что-то другое), а девай только предоставляет различные области памяти для Boot, RootDirectory, FAT12. и собственно, содержимому файлов. Для одного большого файла оно давно и успешно применяется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Я не описывал подробностей, т.к. недумал что это имеет значение к вопросам исключительно по FAT, но видимо придется - файлы расположены на USB MSD девайсе, подключаемому к компу, поэтому всей работой с файловой системой занимается винда (ну может один из тысячи и будет использовать что-то другое), а девай только предоставляет различные области памяти для Boot, RootDirectory, FAT12. и собственно, содержимому файлов. Я не понял, почему нельзя сделать в данном случае просто полную совместимость снаружи с FAT, зачем какие-то ограничения? просто перекодируете внешние запросы фата к секторам в запросы к памяти и все. Задача классическая и решение много где описано- эмуляция фата на флеше. У майкрочипа есть отличный аппноут, ищите по "Microchip Memory Disk Drive File System", я когда-то его как основу использовал для похожей задачи: кусок памяти прикидывался маленькой юсб флешкой с FAT12. Доступ к Boot и Root у меня вообще в микроконтроллер обрабатывал (реально таких секторов не хранил, память экономил), а остальное- в изменяемой флешке. Обязательно нужно полностью поддерживать фат без всяких ограничений "что, куда, как и сколько писать" - эти ограничения будут жить до первого юзера и прибор придет в ремонт. Или же это случится из-за запуска формата-чекдиска-посекторного редактора- любая из этих софтин должна нормально работать с Вашей "флешкой". Или вообще не используйте FAT, или делайте все правильно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Allregia 9 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба или делайте все правильно. "Правильно" - это как? Я не понял, почему нельзя сделать в данном случае просто полную совместимость снаружи с FAT, зачем какие-то ограничения? Так и сделано - снаружи полная соввметимость. просто перекодируете внешние запросы фата к секторам в запросы к памяти и все. Это и сделано - ФАТ ссылается на сектора в памяти. Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам. Микрочиповскую аппноту я знаю, но не очень понял причем тут она - в ней как использовать память как диск, это совсем другое и у них там нет задачи размещать файлы по конкретным адресам в памяти. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Но мне нужно, чтобы File_A и File_B всегда в памяти размещались по конкретным адресам. Зачем? Вам же говорят забейте на сектора! Вы знаете таблицу FAT и при обращении к сектору вы можете понять смещение в файле. Зная смещение, выдавайте порцию данных, которая этому смещению соответствует. Данные вообще могут быть не в секторах, а генерироваться на лету. Компу с Виндой тоже будет легче, т.к. запись в файл стандартными средствами позволит вам задавать только смещение в файле без необходимости указывать физические сектора. Кста: вы же таблицу FAT можете генерить на лету, а не где-то хранить. Можно при каждом новом подключении генерить эту таблицу так, чтобы фрагментации не было вообще. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Allregia 9 19 октября, 2016 Опубликовано 19 октября, 2016 · Жалоба Зачем? Вам же говорят забейте на сектора! Вы знаете таблицу FAT и при обращении к сектору вы можете понять смещение в файле. Именно так и делается. Зная смещение, выдавайте порцию данных, которая этому смещению соответствует. Данные вообще могут быть не в секторах, а генерироваться на лету. Компу с Виндой тоже будет легче, т.к. запись в файл стандартными средствами позволит вам задавать только смещение в файле без необходимости указывать физические сектора. Кста: вы же таблицу FAT можете генерить на лету, а не где-то хранить. Можно при каждом новом подключении генерить эту таблицу так, чтобы фрагментации не было вообще. Таблица ФАТ и RootDir и генерируются каждый раз при включении, конечно без фрагментации. В общем, проблема может быть только если сначала удалили оба файла, а потом записали первый маленький и затем большой - тогда маленьккий попадет в начало а большой за ним, изначально оно наоборот. Но ничего страшного не случится - надо будет просто переподключить устройство к компу и записать заново, уже в правильном порядке, или не удалять файлы а просто перезаписывать (т.е. копировать туда новый файл но с тем-же именем). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 20 октября, 2016 Опубликовано 20 октября, 2016 · Жалоба В общем, проблема может быть только если сначала удалили оба файла, а потом записали первый маленький и затем большой - тогда маленьккий попадет в начало а большой за ним, изначально оно наоборот. Т.е. если файлов нет, Винда начинает писать какие-то сектора данных, и вы ничего не знаете о назначении этих данных. Затем идет запись в таблицу FAT, и задним числом мы догадываемся, что запись данных относилась к тому или иному файлу. Поскольку таблица FAT может кешироваться на стороне Винды, то любые манипуляции с размещением файлов приведут к тому, что у вас не будет актуальной информации к какому файлу какие данные относятся. Причем, очень долго. В этом проблема? Как это побороть стандартными средствами? Как устройство может запросить слив всех буферов? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 20 октября, 2016 Опубликовано 20 октября, 2016 · Жалоба Но ничего страшного не случится - надо будет просто переподключить устройство к компу и записать заново, уже в правильном порядке, или не удалять файлы а просто перезаписывать (т.е. копировать туда новый файл но с тем-же именем). Имхо - это всё равно ничего не гарантирует. Всё зависит от дров винды (или не винды) - как они будут распоряжаться кластерами. Им никто не мешает даже на чистый диск записать файл с конца диска или с середины к примеру или раскидать кластера файла как угодно. Тут надо подходить к решению проблему наверное с другой стороны. Может сначала узнать - зачем это вообще нужно - чтобы большой файл был в начале флешь, а маленький - в конце (если я правильно понял)? Может тогда и найдётся другое решение, неочевидное ТСу. Если на стороне винды пишет Ваше ПО, то в винде насколько помню есть функции позволяющие сделать некешируемую запись на диск (или сбросить кеш записи). Но опять-же - никто не гарантирует как драйвер ФС винды преобразует смещения в файле в кластера FAT. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться