Чтение файлов от конца к началу

← →
X_Tra (2005-03-15 20:04) [0]

Вот тут такой вопрос меня интересует.
Насколько я знаю, все существующие в Дельфи функции/процедуры чтения файлов читают блок байт из файла от начала блока к концу и переводят файловый указатель вперёд, устанавливая его на позицию сразу после конца блока.
Хотелось бы узнать, можно ли эту операцию обратить, то есть: прочитать блок байт с конца к началу, сразу заполняя буфер соответствующим образом? А можно ли таким же образом организовать запись в файл? Если можно, то как?

← →
Anatoly Podgoretsky © (2005-03-15 20:12) [1]

Побайтовое чтение и перемещение указателя на два байта назад.

← →
X_Tra (2005-03-15 20:19) [2]

Да это-то я и так знаю, но это ведь будет работать немного медленнее. Имеется ввиду нечто низкоуровневое, когда файловый указатель после чтения перемещается не вперёд, а наоборот назад, и буфер, куда производится чтение, заполняется также задом наперёд. Как такое сделать? Прямым обращением к жёсткому диску?

← →
Anatoly Podgoretsky © (2005-03-15 20:28) [3]

Если знаешь, то зачем спрашиваешь.
Сделать это так "Побайтовое чтение и перемещение указателя на два байта назад."

← →
X_Tra (2005-03-15 21:29) [4]

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

← →
Sphinx © (2005-03-15 21:47) [5]

А кто Вам сказал что ОС разрешит нечто низкоуровневое ?
Времена когда это было просто сделать канули в лету вместе с DOS-ом...
Зачем вообще так извращаться ?
Ответ Вам дали, чем Seek не устраивает ?

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

> Я понимаю, что с нынешними HDD (с их скоростями и буферизацией)
> замедление операции будет совершенно незаметно
Я бы и на старый компах не заметил, если использовать потоки, размещенные в оперативной памяти...

← →
Fay © (2005-03-15 21:59) [6]

CreateFileMapping & K

← →
X_Tra (2005-03-15 22:24) [7]

> А кто Вам сказал что ОС разрешит нечто низкоуровневое ?
Никто мне этого не говорил, я и сам прекрасно понимаю, что в ОС таких возможностей быть не может

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

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

← →
llirik © (2005-03-16 00:42) [8]

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

CreateFile
CreateFileMapping

← →
Defunct © (2005-03-16 01:24) [9]

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

Последний кластер будет заполнен не полностью. Поэтому для начала определите объем информации последнего кластера файла, прочитайте его назовем его "остатком", а дальше дело техники FileSeek( FileHandle, <Длина файла - №Блока * Размер кластера - Остаток>, soFromEnd)

← →
X_Tra © (2005-03-16 18:51) [10]

> Defunct © (16.03.05 01:24) [9]
Спасибо, теперь всё ясно: про то, что винчестер в одну сторону вращается, я как-то не подумал :)
А как быть с удалением/вставкой блока байт в уже имеющийся файл (см. мой вопрос выше)?

← →
Игорь Шевченко © (2005-03-16 19:01) [11]

Defunct © (16.03.05 01:24) [9]

Винчестеру вообще-то пофиг, как с него данные читают.

X_Tra © (16.03.05 18:51) [10]

> А как быть с удалением/вставкой блока байт в уже имеющийся
> файл

Использовать временный файл.

← →
Alexander Panov © (2005-03-16 19:05) [12]

Игорь Шевченко © (16.03.05 19:01) [11]
Винчестеру вообще-то пофиг, как с него данные читают.

Но пишется-то в соответствии с направлением вращения диска.;)

← →
Игорь Шевченко © (2005-03-16 19:07) [13]

Alexander Panov © (16.03.05 19:05) [12]

> Но пишется-то в соответствии с направлением вращения диска

Кто сказал ? :)

← →
X_Tra © (2005-03-16 19:15) [14]

> Использовать временный файл.
Я не хочу этого делать, см. пояснение в X_Tra (15.03.05 22:24) [7]

← →
Alexander Panov © (2005-03-16 19:16) [15]

Игорь Шевченко © (16.03.05 19:07) [13]
А как иначе?

← →
Alexander Panov © (2005-03-16 19:16) [16]

X_Tra © (16.03.05 19:15) [14]
Я не хочу этого делать,

По-другому никак.

← →
Игорь Шевченко © (2005-03-16 19:18) [17]

X_Tra © (16.03.05 19:15) [14]

> Я не хочу этого делать

Не делай. Но иначе не получится.

← →
X_Tra © (2005-03-16 19:28) [18]

> Не делай. Но иначе не получится.
Да ё-моё, всё уже давно работает, и именно таким методом: открываем файл размером в 4 ГБ и удаляем оттуда маленький блок в самом начале - операция длится около двух минут без использования временного файла, поблочным перемещением хвоста после блока влево и последующим SetEndOfFile. А если удаляем блок ближе к концу, то вообще операция почти моментально проходит! То же самое со вставкой блока в файл. А если использовать временный файл, то во-первых, длительность операции будет фиксированной для конкретного размера блока и файла, а во-вторых, будет требоваться дополнительное дисковое пространство - два существенных минуса!

← →
X_Tra © (2005-03-16 19:43) [19]

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

← →
Набережных С. © (2005-03-16 19:49) [20]

> X_Tra © (16.03.05 19:28) [18]

А Чубайс c рубильником?

← →
X_Tra © (2005-03-16 19:55) [21]

> Набережных С. © (16.03.05 19:49) [20]
Волков бояться - в лес не ходить:)
Поэтому и хочу через кластеры сделать

← →
Набережных С. © (2005-03-16 20:12) [22]

> X_Tra © (16.03.05 19:55) [21]

Ты бы сообщил, какую программу пишешь. Ну на всякий случай, вдруг столкнусь

← →
Anatoly Podgoretsky © (2005-03-16 20:24) [23]

Предусмотрительный какой :-)

← →
X_Tra © (2005-03-16 20:29) [24]

> Набережных С. © (16.03.05 20:12) [22]
Это намёк на мою некомпетентность, что ли? Ну-ну... Отличный разговор на форуме :-(
Не беспокойтесь, this program is for private use only...

> X_Tra © (16.03.05 20:29) [24]

Нет, это намек на наплевательское отношение к вопросу надежности.

> this program is for private use only

Это радует. Только не передумай.

> Anatoly Podgoretsky © (16.03.05 20:24) [23]

А что делать?:(

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

> Это радует. Только не передумай.
Не надо язвить, я не собирался и не собираюсь эту программу выкладывать в инете, не собираюсь её shareware делать, просто надеялся, что кто-то что-то знает или поможет мне найти дополнительную информацию. Вы же меня пытаетесь разубедить, что то, что я делаю, невозможно, а когда выясняется, что возможно, Вы сразу подразумеваете, что я сделал это с грубыми ошибками, и Вы ни в коем случае бы не стали использовать мою программу и никому бы этого не порекомендовали. Очень странный подход... :-\

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

Это не совсем так. Или не всегда так. Или даже совсем не так.

> X_Tra © (16.03.05 21:19) [26]

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

> хотя это надо поточнее узнать в Microsoft

С этого и надо начинать.

> Просто Джо © (16.03.05 21:24) [27]

Третье.

И более - так не надо работать в многопрограммных/многопользовательских системах.

> Вы всерьез полагаете, что до столь простой вещи додумались первым в мире?
Вовсе нет, с чего Вы это взяли? Я такого не говорил, я как раз и думал, что, возможно, кто-то на этом форуме с этим имел дело, и поэтому задал вопрос

> С этого и надо начинать.
Ну и как это узнать? Они не скажут. Может, Вы знаете, как работает FileClose? Как именно эта функция освобождает хендл файла?

> Так почему же так не делает ни одна серьезная программа?
Во-первых, моя программа не претендует на то, чтобы перейти в раздел профессиональных - я программист-любитель.
Во-вторых, Вы можете навскидку назвать парочку программ-редакторов, которые умеют быстро работать с файлами любого размера и выполнять операции такого типа? В основном, все программы виснут, если только попытаться открыть в них файл размером больше 20-30 МБ (а то и всего 5 МБ), не говоря уже о том, чтобы его отредактировать и сохранить. Именно потому, что я не нашёл такой программы, пришлось писать свою. Ни одна серьёзная программа-редактор так не делает, потому что не рассчитана на файлы большого размера - для маленьких файлов проще всего использовать временный файл или разместить весь файл в памяти и там с ним работать...

> И более - так не надо работать в многопрограммных/многопользовательских системах.
Почему? А как насчёт дефрагментаторов? Они ведь на уровне кластеров работают, и прекрасно уживаются с многопрограммными/многопользовательскими системами. Там тоже есть опасность рубильника Чубайса, но никто на это не ругается

> [30] X_Tra © (16.03.05 22:47)
> Почему? А как насчёт дефрагментаторов?
> системами. Там тоже есть опасность рубильника Чубайса, но
> никто на это не ругается

А знаете почему? Потому, что они совсем не наплевательски сделаны.
В принципе, там, конечно, есть узкие места, увы. Но ооочень кратковременные! Вот в чем фокус. При том, там нет такого места, чтобы потерялся 4 гиговый файл.

> [30] X_Tra © (16.03.05 22:47)
> Во-вторых, Вы можете навскидку назвать парочку программ-редакторов,
> которые умеют быстро работать с файлами любого размера и
> выполнять операции такого типа?

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

> Потому, что они совсем не наплевательски сделаны.
{Здесь подразумевается, что моя программа сделана наплевательски - это по меньшей мере не тактично}

> Но ооочень кратковременные! При том, там нет такого места, чтобы потерялся 4 гиговый файл.
Да что Вы говорите: если будет нарушена связь хотя бы одного кластера, файл уже потерян.
Ладно, а как насчёт программ переразбивки дисков без потери данных (типа Partition Magic)? Они ведь тоже так работают

> Я не знаю, о каких редакторах речь, но более чем уверен - что есть.
Имеются ввиду такие программы, которые позволяют открыть любой файл любого размера как текст (как Блокнот, например), изменить его и сохранить. По идее, если такие программы есть, то Вы каждому её автору пошлёте гневное письмо с требованием закрыть проект из-за высокой опасности потери данных? Даже если бы я и нашёл такую программу, то не использовал бы её, так как не уверен на 100% в правильности алгоритма другого программиста. Я и своей программе не доверяю, всегда файл отката делаю

> настоятельный совет: не отдавайте никому!!!
Да успокойтесь Вы, НЕ БУДУ Я ВЫКЛАДЫВАТЬ ЭТУ ПРОГРАММУ на всеобщий доступ. Я Вас не заставляю её использовать, не настаиваю на своём алгоритме, я вообще Вас про это не спрашивал: если я сам увижу, что низкоуровневый доступ к жёсткому диску очень сложно осуществить, то брошу эту затею. Но для этого я хочу найти некоторую техническую информацию. Если Вы не знаете, где её найти, не пишите ничего!

X_Tra © (17.03.05 18:36) [32]

Поверьте, Ваша затея не стоит того чтобы за нее браться.

> как работает FileClose?

При закрытии FileHandle ОС сбрасывает на диск буфер файла. Объем буфера кратен объему сектора (512байт), буфер может быть разного размера зависит от ОС и ее настроек от (минимум) одного сектора (DOS) до, хм боюсь соврать ибо не знаю сколько в WinXP но однозначно не меньше одной страницы ОП (4kb).

Таких ситуаций как Вы предположили, что мол после сбоя (откл. питания) незакрытый файл вернется к начальному состоянию - 50/50. Зависит от ветра в поле. Если записывалось больше информации чем объем буфера, то часть информации в файл попадет а часть - нет.

[33]

Это без учета кеширования.

Чтение файлов от конца к началу Найти похожие ветки