Форум: "Основная";
Текущий архив: 2005.03.27;
Скачать: [xml.tar.bz2];
ВнизЧтение файлов от конца к началу Найти похожие ветки
← →
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...
← →
Набережных С. © (2005-03-16 20:54) [25]
> X_Tra © (16.03.05 20:29) [24]
Нет, это намек на наплевательское отношение к вопросу надежности.
> this program is for private use only
Это радует. Только не передумай.
> Anatoly Podgoretsky © (16.03.05 20:24) [23]
А что делать?:(
← →
X_Tra © (2005-03-16 21:19) [26]> Нет, это намек на наплевательское отношение к вопросу надежности.
Что Вам не нравится: изменения сохраняются в файл, только если выполнить FileClose. Если вдруг произойдёт внезапное отключение питания, или кто-то убьёт процесс во время выполнения файловой операции, файл не сломается, не испортится и не удалится, так как функция FileClose не была выполнена. FileClose как раз и записывает окончательную информацию о файле в файловую таблицу (хотя это надо поточнее узнать в Microsoft).
> Это радует. Только не передумай.
Не надо язвить, я не собирался и не собираюсь эту программу выкладывать в инете, не собираюсь её shareware делать, просто надеялся, что кто-то что-то знает или поможет мне найти дополнительную информацию. Вы же меня пытаетесь разубедить, что то, что я делаю, невозможно, а когда выясняется, что возможно, Вы сразу подразумеваете, что я сделал это с грубыми ошибками, и Вы ни в коем случае бы не стали использовать мою программу и никому бы этого не порекомендовали. Очень странный подход... :-\
← →
Просто Джо © (2005-03-16 21:24) [27]
> > Нет, это намек на наплевательское отношение к вопросу
> надежности.
> Что Вам не нравится: изменения сохраняются в файл, только
> если выполнить FileClose. Если вдруг произойдёт внезапное
> отключение питания, или кто-то убьёт процесс во время выполнения
> файловой операции, файл не сломается, не испортится и не
> удалится, так как функция FileClose не была выполнена. FileClose
> как раз и записывает окончательную информацию о файле в
> файловую таблицу (хотя это надо поточнее узнать в Microsoft).
Это не совсем так. Или не всегда так. Или даже совсем не так.
← →
Набережных С. © (2005-03-16 21:36) [28]
> X_Tra © (16.03.05 21:19) [26]
Вы всерьез полагаете, что до столь простой вещи додумались первым в мире? Так почему же так не делает ни одна серьезная программа?
> хотя это надо поточнее узнать в Microsoft
С этого и надо начинать.
> Просто Джо © (16.03.05 21:24) [27]
Третье.
← →
Anatoly Podgoretsky © (2005-03-16 21:39) [29]И более - так не надо работать в многопрограммных/многопользовательских системах.
← →
X_Tra © (2005-03-16 22:47) [30]> Вы всерьез полагаете, что до столь простой вещи додумались первым в мире?
Вовсе нет, с чего Вы это взяли? Я такого не говорил, я как раз и думал, что, возможно, кто-то на этом форуме с этим имел дело, и поэтому задал вопрос
> С этого и надо начинать.
Ну и как это узнать? Они не скажут. Может, Вы знаете, как работает FileClose? Как именно эта функция освобождает хендл файла?
> Так почему же так не делает ни одна серьезная программа?
Во-первых, моя программа не претендует на то, чтобы перейти в раздел профессиональных - я программист-любитель.
Во-вторых, Вы можете навскидку назвать парочку программ-редакторов, которые умеют быстро работать с файлами любого размера и выполнять операции такого типа? В основном, все программы виснут, если только попытаться открыть в них файл размером больше 20-30 МБ (а то и всего 5 МБ), не говоря уже о том, чтобы его отредактировать и сохранить. Именно потому, что я не нашёл такой программы, пришлось писать свою. Ни одна серьёзная программа-редактор так не делает, потому что не рассчитана на файлы большого размера - для маленьких файлов проще всего использовать временный файл или разместить весь файл в памяти и там с ним работать...
> И более - так не надо работать в многопрограммных/многопользовательских системах.
Почему? А как насчёт дефрагментаторов? Они ведь на уровне кластеров работают, и прекрасно уживаются с многопрограммными/многопользовательскими системами. Там тоже есть опасность рубильника Чубайса, но никто на это не ругается
← →
KSergey © (2005-03-17 08:07) [31]> [30] X_Tra © (16.03.05 22:47)
> Почему? А как насчёт дефрагментаторов?
> системами. Там тоже есть опасность рубильника Чубайса, но
> никто на это не ругается
А знаете почему? Потому, что они совсем не наплевательски сделаны.
В принципе, там, конечно, есть узкие места, увы. Но ооочень кратковременные! Вот в чем фокус. При том, там нет такого места, чтобы потерялся 4 гиговый файл.
> [30] X_Tra © (16.03.05 22:47)
> Во-вторых, Вы можете навскидку назвать парочку программ-редакторов,
> которые умеют быстро работать с файлами любого размера и
> выполнять операции такого типа?
Я не знаю, о каких редакторах речь, но более чем уверен - что есть.
А на счет времени - вот когда потеряется ценный материал из файла и возможные пользователи сего чудо-софта (настоятельный совет: не отдавайте никому!!!) придут пинать ногами - не говорите, что вас не предупреждали.
← →
X_Tra © (2005-03-17 18:36) [32]> Потому, что они совсем не наплевательски сделаны.
{Здесь подразумевается, что моя программа сделана наплевательски - это по меньшей мере не тактично}
> Но ооочень кратковременные! При том, там нет такого места, чтобы потерялся 4 гиговый файл.
Да что Вы говорите: если будет нарушена связь хотя бы одного кластера, файл уже потерян.
Ладно, а как насчёт программ переразбивки дисков без потери данных (типа Partition Magic)? Они ведь тоже так работают
> Я не знаю, о каких редакторах речь, но более чем уверен - что есть.
Имеются ввиду такие программы, которые позволяют открыть любой файл любого размера как текст (как Блокнот, например), изменить его и сохранить. По идее, если такие программы есть, то Вы каждому её автору пошлёте гневное письмо с требованием закрыть проект из-за высокой опасности потери данных? Даже если бы я и нашёл такую программу, то не использовал бы её, так как не уверен на 100% в правильности алгоритма другого программиста. Я и своей программе не доверяю, всегда файл отката делаю
> настоятельный совет: не отдавайте никому!!!
Да успокойтесь Вы, НЕ БУДУ Я ВЫКЛАДЫВАТЬ ЭТУ ПРОГРАММУ на всеобщий доступ. Я Вас не заставляю её использовать, не настаиваю на своём алгоритме, я вообще Вас про это не спрашивал: если я сам увижу, что низкоуровневый доступ к жёсткому диску очень сложно осуществить, то брошу эту затею. Но для этого я хочу найти некоторую техническую информацию. Если Вы не знаете, где её найти, не пишите ничего!
← →
Defunct © (2005-03-17 20:04) [33]X_Tra © (17.03.05 18:36) [32]
Поверьте, Ваша затея не стоит того чтобы за нее браться.
> как работает FileClose?
При закрытии FileHandle ОС сбрасывает на диск буфер файла. Объем буфера кратен объему сектора (512байт), буфер может быть разного размера зависит от ОС и ее настроек от (минимум) одного сектора (DOS) до, хм боюсь соврать ибо не знаю сколько в WinXP но однозначно не меньше одной страницы ОП (4kb).
Таких ситуаций как Вы предположили, что мол после сбоя (откл. питания) незакрытый файл вернется к начальному состоянию - 50/50. Зависит от ветра в поле. Если записывалось больше информации чем объем буфера, то часть информации в файл попадет а часть - нет.
← →
Defunct © (2005-03-17 20:11) [34][33]
Это без учета кеширования.
Страницы: 1 вся ветка
Форум: "Основная";
Текущий архив: 2005.03.27;
Скачать: [xml.tar.bz2];
Память: 0.56 MB
Время: 0.037 c