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

единственное что может пофачить - коллизии хешей

рандомные данные [[[данные|||сигнатура|||длинна]]] рандомные данные

Можно и так, пожалуй. Ну, я пришёл к оптимальному по мне: [нз данные заголовока кз]данные

обычно указывают длину загаловка, а не ставят маркеры конца загаловка

Можно указывать длину, но тогда появляется лимит имени : ) А если я хочу имя на 100мб ))))

не появится, если указать длину имени

ну или хотябы порядок длины

типа 32 байта

Тогда уж ещё длину длины имени, чтобы в 32 байта влезло : )

ну если хочется борщить, то почему бы и нет.

и всё просолить хорошенечко

Я руководствовался комфортом. Минимум отдельных процедур: 1. выдираем предполагаемые заголовки 2. сплитим то что получили на отдельные строки, не сплитится - или что-то неправильно - удаляем 3. парсим то что получилось в ООП-стайл. Можно оптимальнее: 1. Выдираем заголовок и парсим его в ООП-стайл 2. Смещаемся на длину файла из заголовка 3. Ищем следующий заголовок Так проще всего, на мой взгляд.

А можно еще и заголовки отдельно от данных хранить

Вот я думал на эту тему, но тогда не получится записывать в архив новые данные.

или даже хранить словарик с адресами начал ахивных данных

но всё это пустое

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

у игры Смешбандикут были забавные приключение с умести игру на диск

почитай, там - космос

Хех, линк есть? : )

или видос на тытрубе глянь

Можно и так, пожалуй. Ну, я пришёл к оптимальному по мне: [нз данные заголовока кз]данные

Погоди, в одном "контейнере" может быть несколько упакованных данных?

блин, я поищу

Погоди, в одном "контейнере" может быть несколько упакованных данных?

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

Тогда твой формат. Ну, он много может отбросить файлов, если тебе попадется джекпот в виде тех возможных имён

И вообще в топку имена в таком, на самом деле. Это должно быть уже в своих данных

Тогда твой формат. Ну, он много может отбросить файлов, если тебе попадется джекпот в виде тех возможных имён

Значит сделаем имена невозможными. Сигнатура начала-конца может содержать непечатаемые символы. Любая здравая ОС не даёт делать файлы с bell-символами, иначе каждый раз когда ты бы открывал папку с этим файлом - твой комп бибикал бы )))

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

Но потерь файлов от неправильного имени просто не будет как факта

http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/

снус, лучше скажи для дэбила, как передать по удп сокету данных больше чем мту?

тупым разделением не получается

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

Но потерь файлов от неправильного имени просто не будет как факта

Три раза блин сказал, как это исправляется )))

Значит сделаем имена невозможными. Сигнатура начала-конца может содержать непечатаемые символы. Любая здравая ОС не даёт делать файлы с bell-символами, иначе каждый раз когда ты бы открывал папку с этим файлом - твой комп бибикал бы )))

Эмм... Какая такая система парсит файлы на белл-символы при открытии?

Бред какой-то сказал.

снус, лучше скажи для дэбила, как передать по удп сокету данных больше чем мту?

Там не совсем MTU, там 8кб (типа, умные сетевые карты умеют в передачу UDP больше чем MTU, но ничего не гарантируют, если повреждение хоть в одном пакете MTU - сообщение утеряно полностью), но для этого тебе нужен протокол передачи поверх UDP, который позволяет . 1. Не использовать UDP 2. Написать свой протокол поверх UDP, который сделает всё заебись. Я так и сделал.

Там не совсем MTU, там 8кб (типа, умные сетевые карты умеют в передачу UDP больше чем MTU, но ничего не гарантируют, если повреждение хоть в одном пакете MTU - сообщение утеряно полностью), но для этого тебе нужен протокол передачи поверх UDP, который позволяет . 1. Не использовать UDP 2. Написать свой протокол поверх UDP, который сделает всё заебись. Я так и сделал.

UDP это нечто среднее между сырым использованием сети, и , TCP

Эмм... Какая такая система парсит файлы на белл-символы при открытии?

Ты не можешь создать файл, с именем содержащим почти любой символ из таблицы до 37.

Ты не можешь создать файл, с именем содержащим почти любой символ из таблицы до 37.

На какой системе? Это всё зависит от Файловой Системы полностью

Боюсь что ни на какой распространённой ))) FAT/NTFS/EXT1-2-3. Только человеческие, печатные символы.

Во, слушай, как файловая система различает, что на ЖД - файл, а что - нет? : ) ЖД - это же просто огромный плоский набор битиков.

Во, слушай, как файловая система различает, что на ЖД - файл, а что - нет? : ) ЖД - это же просто огромный плоский набор битиков.

Блоки.

Ты имеешь ввиду, кластеры? Маловато будет. Плюс кроме кластеров там ещё что-то должно быть. Да и кластеры имеют сложную структуру, мда. Блин, мы все живём в мире, созданном гениальными людьми. Кошмар.

Есть таблица разметки жёсткого диска. Потом в самом начале этого раздела идёт некий корневой блок Файловой Системы, определенного размера. Всё данные упакованы в другие блоки такогоже размера, разбитые по этим блоки если надо

Это только у FAT : )

Остальные работают на том же принципе

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

Если ты мне покажешь хоть одну файловую систему не основанную на блоках, за исключением tar и фиксированных файлах систем, я тебе дам медальку воздушную

Воу

Я запилю свою файловую систему, без блекджека и блоков )))

http://all-things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/

Сяп

Есть что-то интересное, что стоит почитать?

Я запилю свою файловую систему, без блекджека и блоков )))

На токенах и экранировании?

На деревьях и безудержной фрагментации. Но зато без блоков )))

А теперь подумай.. вот было у тебя три файла. Средний удалили. А теперь пытаются записать новый, больше среднего.

Я уже написал.

На деревьях и безудержной фрагментации. Но зато без блоков )))

Поздравляю, ты изобрел те же самые блоки, но в гораздо более неудобном формате

Ну не, не блоки : ) Сами файлы - занимают единое неделимое пространство, тут нет блоков : ) Ой, как вариант - я уже сделал без блоков. Заголовок + тело : ) Если что-то удалили - заголовок с телом затираются в ноль.

Кстати да, фрагменты - пустого пространства, имеются ввиду.

А как ты поймёшь, где и сколько у тебя пустого пространства?

И что это не просто внутри файла?

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

И ты итеративно будешь бегать по диску и считать?

Если нашли заголовок - с прошлого заголовка + длины того тела до текущего заголовка - пустое пространство.

Конечно : ) Но зато смотри, уже есть гордое название "файловая система", и она без блоков ))

ERROR: S client not available

... это самая хреновая файловая система в мире

Нигде не сказано что она должна быть хорошей, достаточно "без блоков", и самой возможности хранения файлов. Какое ТЗ - такой и проект )) И да, это ещё далеко не худших вариант : )

Куда хуже то?

Хмм. Например, когда мы дописываем только в конец "диска", не используя пустое пространство. Диск приходится часто форматировать, хотя как память для прошивки микрухи - пойдёт. Ты веришь что может быть ещё хуже? Я могу продолжить ухудшать : )

Хмм. Например, когда мы дописываем только в конец "диска", не используя пустое пространство. Диск приходится часто форматировать, хотя как память для прошивки микрухи - пойдёт. Ты веришь что может быть ещё хуже? Я могу продолжить ухудшать : )

Вроде на ленту так и пишут, не?

Если ты мне покажешь хоть одну файловую систему не основанную на блоках, за исключением tar и фиксированных файлах систем, я тебе дам медальку воздушную

В тар же есть блоки :3

Тар - не файловая система, насколько я знаю, просто способ упаковки файлов в другой файл. Или ещё и ФС?

В тар же есть блоки :3

...лолчто? Блоки там такие же, как у персонажа выше. Заголовок с длинной и данные. И так для каждого файла

tar - Tape ARchive

Это чисто линейный формат хранения файлов

Тар - не файловая система, насколько я знаю, просто способ упаковки файлов в другой файл. Или ещё и ФС?

Гм, надо глянуть на том, что мкйнфремы хранили на лентах, и как

Ты изобрел TAR?

...лолчто? Блоки там такие же, как у персонажа выше. Заголовок с длинной и данные. И так для каждого файла

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

Ты изобрел TAR?

Угу ))) Я даже не читал доки по нему.

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

А это кажется то, что мурлыкал шнуш

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

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

Итак, давайте дружно петь песню: "Снус изобрёл велосипед Никто его не просил, а он всё равно изобрёл. И им никто никогда не будет пользоваться кроме снуса (и то не факт) Вот такой классный велосипел" )))

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

Вообще с появлением реализаций fat32 для микроконтроллеров это всё неактуально, имхо

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

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

А мне блочные системы файловые нравятся :3

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

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

Только вот.. там условие - не тар :Р только вот учитывая это, в принципе ничего другого не получится придумать. TAR это практически концепция, кроме формата

Я расписал методику работы с дырками, уже не тар :P

Интересно, как тар работает с перезаписью и удалением файла в архиве?

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

В файлах нельзя создавать дырки. Варианта два: 1. Дописать в конец: "Такой-то файл удалён", чтобы читалка файла удалила объект из структуры внутри себя 2. Перезаписать всё нафиг, но уже без файла То же самое - с редактированием. Редактирование в принципе возможно только в одном случае: мы дописываем в конец последнего добавленного файла Мой "формат тара" это тянет. Хм.

Интересно, как тар работает с перезаписью и удалением файла в архиве?

Никак он не работает

Там вообще нельзя удалить файл без костылей

А, в новых версиях есть

В новых версиях tar архиватора