Извините, может тупой вопрос. Есть большой файл, скажем 2Гб. Пусть мне нужно в середину этого файла вставить 4 байта. Для этого что, нужно будет весь оставшийся хвост перетаскивать? Или есть какие-то еще элементарные операции кроме read(), write() и seek()?
На уровне фс будет чуть проще в том плане, что не придётся копировать половину всего файла: определяешь необходимый фрагмент файла (куда вставить надо), смотришь, есть ли свободное место для перемещения, если нет - копируешь в другое место и пишешь, что нужно. И правишь ссылки на блоки. Но это теория.
IceStudent Ну, это оччень круто! И все портит 4 байта, был бы размер блока, тогда можно было бы геморрнуться.
пора создавать собственную фс по теме: а может у sparced'ов есть какие-нибудь фишки.. никто как следует не разбирался?
IceStudent про них насколько я себе представляю, в спарседах хранятся отдельные блоки данных + инфа о смещениях этих блоков внутри файла при обращении к смещению, попадающему на такой блок, драйвер фс возвращает соответствующие данные, если же смещение не попадает ни в один из блоков - нули так что если подправить инфу о смещении одного из таких блоков - данные этого блока мгновенно перенесутся в другую часть файла без копирования просто мелкомягкие не стали делать соответствующие ioctl единственное, чего я не знаю - это как блоки хранятся физически - если они должны начинаться с начала кластера, то с реализацией сабжа возникают проблемы: если упомянутые 4 байта нужно будет вставить в середине кластера.. дальше понятно с другой стороны, если это так, то как тогда будет работать код FSCTL_SET_ZERO_DATA, если FileOffset и BeyondFinalZero не выровнены на границы кластеров? и, в конце концов, даже если блоки должны начинаться с начала кластера, можно расщепить блок на три части: одна до модифицируемого кластера, вторая после, и третья - сам кластер, куда и будут вставлены данные просто microsoft пожадничала сделать такие ioctl'ы или я что-то неправильно понимаю?
IceStudent Не понял - разве в середине файла может быть не заполненный кластер с 4 байтами, а остальное пусто? ИМХО в FAT такое только на хвосте висеть может или в NTFS по другому?
В принципе ничего не мешает создать свою ФС, где файл будет храниться как связный список, т.е. блок инфы + указатель на следующий блок. А может такие ФС уже есть, для линукса, например. Если знаете, подскажите (только желательно чтобы был системный интерфейс для манипуляции блоками). Кстати, в reiserfs с включенным tail-packing-ом маленькие файлы ужимаются в один кластер.
Ss_oO0 Дык в принципе и ФС для этого не обязательно - достаточно своего формата файла, который сам по себе может быть связанным списком - М$ офис так и поступает и не только он
Y_Mur Да, ты прав - вставка повлечёт за собой изменение остальных кластеров, если только она не кратна размеру кластера. Ss_oO0 Практически все существующие ФС так и сделаны, просто размер блока у них фиксированный. В NTFS файлы, меньше 1кб вообще "не занимают" место на диске - они хранятся в таблице размещения файлов.
