VBS : подскажите как - Построчное чтение текстовых файлов с конца

2 Dmitrii > откуда такие установки - 10MB ?
То , о чем Вы сказали, не подразумевает построчное чтение, а подразумевает чтение ЦЕЛИКОМ.

Тип файла указан - текстовый, с разбитием на строки символами VbCrLf , размер,раз не указан,то значит, естественно - любой разумный размер (ну или по усмотрению разработчика идеи) .

Из суммы опыта сообщества участников данного форума и личного опыта.

Чтение целиком выполняется как раз для того, чтобы получить возможность чтения строк в обратной последовательности. Коль скоро Вас не устраивает такой способ, могу посоветовать следующее:
- открыть файл в каком-либо приложении, поддерживающем средства Automation (скажем, в MS Word);
- читать нужные строки в нужном порядке, обращаясь из сценария к элементам объектной модели приложения.
Если и этот вариант не подходит, то Вам прямой путь к средствам организации произвольного доступа к файлу либо непосредственно с помощью функций WinAPI, либо опять-таки с помощью средств какого-нибудь приложения.
Впрочем, здесь, если мне не изменяет память, Вы столкнётесь с одним ограничением - при произвольном доступе чтение выполняется не построчно, а поблочно или побайтово. Следовательно, придётся решать задачу идентификации начала и конца строки.

Если Вы считаете, что сделанное Вами в исходном сообщении темы описание задачи носит исчерпывающий характер, то Вы ошибаетесь.

При такой постановке вопроса ответ однозначно отрицательный.

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

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

Проблема в том, что неизвестно, с какого места начинается n-ная (не первая) строка файла. Где заканчивается n-ная (не последняя) строка. Точно так же ничего неизвестно о том, сколько, например, строк в файле. Таким образом, единственным способом добраться до n-ной строки, является метод последовательного чтения от начала файла к концу файла (чтобы лучше представлять, чем сие обусловлено — посмотрите, например, на функцию ReadFile (Windows)).

Можно, конечно , где-то (отдельно или в том же файле) хранить смещения, где начинаются очередные строки, и пользоваться этими данными. Про такой механизм уже упомянул выше коллега Slav, говоря о базах данных. Но, естественно, сие уже не будет являться «текстовым файлом последовательного доступа».

Коллега, тут Вы путаете семантически разные вещи. Повторю — физическая организация хранилища не имеет никакого отношения к логическому методу доступа к файлу.

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

Так вот, при хранении в файле структурированных данных (проще говоря — набор из элементов одинакового размера) становится возможным произвольный доступ к n-ному элементу, поскольку в данном случае возможно рассчитать смещение от начала файла этого n-ного элемента как «(n-1)*размер элемента (структуры)+1», а количество необходимых для прочтения/записи байт — есть сам размер элемента/структуры. [И читайте его хоть с начала, хоть с конца — причём тут HDD, кластеры и старшие/младшие адреса?!]

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

Update: Приношу свои извинения за некорректно подобранные ссылки; правильные [отчасти ] ссылки таковы:
Последовательные файлы
Файлы с произвольным доступом

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

Угу , аналогично, коллега.

Только сие опять-таки имело отношение к физическому чтению данных с носителя. Вы же не хотите сказать, что это позволяло сразу «прочитать» заданную n-ную строку из такого «файла»?

Думаю, что теоретические разработки развивались параллельно реальным возможностям по их воплощению, хотя и несколько опережая последних.

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

Бессмысленный разговор получается. Я Вам про Фому, Вы мне про Ерёму.

alexii,

у меня ощущение, что мы обсуждаем разные вопросы.
Я пытаюсь объяснить (в том числе и самому себе - это бывает очень полезно) вот это:

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

Еще раз повторюсь - чтение в любом направлении не поддерживается именно файловой системой. Потому и в языках программирования есть Read, но нет что-то типа ReadForward - ReadBackward. По той простой причине, что реализовать ReadBackward физически невозможно.

В подтверждение своих слов могу привести пример файловой системы, которая эту возможность поддерживает. Запишите на лазерный диск файл любого фильма, вставьте в плеер и посмотрите минут 5-10. А затем нажмите кнопку  "<". И посмотрите то же самое в обратном направлении. Оказывается ничего невероятного в этом нет.
Просто файл записан так, что логические блоки четко соответствуют расположению физических секторов. И для чтения в прямом направлении надо считывать последовательно n, n+1, n+2... сектора, а для чтения в обратном - n, n-1, n-2... Файловая система жесткая и не очень удобная - но зато именно чтение в любом направлении поддерживает.
И для этого никаких специальных "системных средств" не нужно.

Соглашусь с kefi, что так и не понятно, почему нельзя читать построчно с конца. Да, конец нужно сперва найти, ну и что? Когда он найден, что мешает найти начало последней строки и считать её? И n-ую строку с конца тоже можно найти. Что тут невозможного? При чём здесь файловая система и прочее?

Насколько я понял, автору темы нужен метод вроде ReadLine, но который возвращал бы строки, начиная с последней, а не с первой. Вот и всё. Что здесь невозможного?

Я думаю основной причиной отсутствия API для чтения файлов с конца является то, что это нафиг никому не нужно . Во-первых это медленнее из-за того, что нужно постоянно перемещать указатель по файлу(читать в обратную сторону бесполезно, ведь всё равно порции по 512 байт надо расшифровывать, а каждые 16 кластеров распаковывать(верно для NTFS)), а во-вторых есть такой объект ядра как "проекция файла"(FileMapping), который позволяет работать с файлом так, будто он находится в памяти, а не на внешнем носителе.

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

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

Если в каждых строках огромного лога есть известный шаблон текста, например, текущая/вчерашняя дата, то предлагаю подумать об использовании консольных команд системы. Идея такова - создать строку запуска команды findstr по поиску в  текстовом файле даты указанного в параметрах образца (+ некая гибкость в применении регулярных выражений) - а сохраненный вывод уже обрабатывать скриптом.
Думаю, что такая встроенная команда отработает побыстрей построчного чтения скриптом или записи всего файла в массив.

VBScript: работа с большими текстовыми файлами
Ещё можно подумать о загрузке файла в специальную БД MS SQL Server, такую загрузку можно автоматизировать, сейчас не вспомню как именно, но в MS SQL Server вроде были такие возможности "малой кровью". Дальше работать с этой БД запросами.

ADO позволит сделать SELECT, который будет быстро работать. А как уж оно само там "в душе" будет читать, это его трудности .

Dmitrii,

ну давайте "договоримся".
1. Приведенная Вами функция getc() продвигает указатель к началу файла или к концу?
2. Известна ли Вам хотя бы одна функция чтения, которая продвигает указатель к началу файла, что-то типа getc(-1)?
Подчеркиваю, не перемещает виртуальный указатель - это не чтение - а именно читает, и именно к началу?

1. Я не вижу большой разницы между тектовым файлом и любым другим - разве что CR - LF встречается чаще и этому сочетанию придан особый логический смысл.
2. Любой файл "на оптическом диске" (файловая система UDF) без значительных вычислительных затрат может быть прочитан в любом направлении. Просто "читалки" на плеерах пока никто не додумался делать.
И реализуется эта возможность "вперед-назад" на уровне элементарной микросхемы - правда, при жесткой организации самой файловой системы.
3. Любая файловая система с жесткой организацией позволяет относительно просто реализовать алгоритм "обратного чтения". Я уже приводил пример с перфокартами.
Если Вы на абсолютно чистый винт запишете файл - то формально он будет соответствовать условию "обратного чтения". Но! Файловая система все равно будет знать из каталога только первый кластер, а в каждом будет только ссылка на последующий.
Так что "в конец" придется все равно идти по всей цепочке.

The gray Cardinal,

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

Но на этом форуме меня всегда поражали изящные и лаконичные решения в 2-3 десятках строк, написанных в обычном Блокноте.
Жаль, что кроме ReadLine и ReadAll ничего другого мы не нашли.

Или плохо искали?

Насколько верно я сужу по документации - у объектов WSH нет методов работы с нетекстовыми файлами - всевозможные Open/CreateTextFile, OpenAsTextStream и единственный объект - опять же TextStream. Но последний имеет два метода SkipLine и Skip. Последний - аналог seek.

Если в постановке задачи нет ограничений на использование внешних утилит, то я бы порекомендовал использовать юниксовые  порты команд (например, http://unxutils.sourceforge.net/):
tail -n - чтение последних n строк из файла
tac - команда, выводящая в STDOUT строки указанных файлов в обратном порядке

Александр_,

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

Спасибо за экскурс в NTFS.
Действительно, интересно.
Насколько я знаю, там еще сложнее - те же индексы.
Но вот для "обратного чтения" все это как-то не очень.
Исключительно по моему скромному мнению.

Тогда это очевидно сводит задачу к SetFilePointer/ReadFile. Причём посекторное чтение таким способом в разы снизит производительность(в секунду диск делает меньше 20-ти оборотов, если попробовать ускорить, то мы можем просто уничтожить диск:)).