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

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

На мой взгляд интересно обсудили.

Особенная благодарность Rumata.
Про Skip я не знал.
На данный момент лично для меня - то что надо.

Ага, надо только заставить сидюк диск в обратную сторону крутить

Александр_,

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

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

В данном случае вынужден повторить Ваши слова: "Мы обсуждаем разные вопросы".

... seek, конечно, не чтение "с конца" - но все-таки на порядок лучше чтения мусора с самого начала...

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

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

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

Ага, надо только заставить сидюк диск в обратную сторону крутить

Нет, это не совсем так. Привожу пример организации на NTFS, про MFT и т.п. не рассказываю, поскольку сейчас это не важно. Запись файла выглядит примерно вот так:

|стнадарт.инфо.|имя|данные|

Каждый из этих атрибутов состоит из заголовка и значения. Но размер записи фиксирован(если не ошибаюсь, то 1кб). Если данные не уместились то этот атрибут называется нерезидентным, в таких случаях под хранение данных выделяется дополнительное пространство вне MFT(буржуи называют его "run" или "extent", у нас обычно просто "группа"). И вот тут на помощь приходит LCN- это нумерованная от 0 до N последовательность кластеров на всём томе, и VCN- аналогичная нумерованная последовательность, но только для каждого файла своя(т.е. нумеруются только кластеры принадлежащие файлу). Т.о. данные выглядят так:
|Начальный VCN|Соответствующий ему LCN|число кластеров|
Таким образом файловая система знает не только первый кластер:). Например если файл занимает 16 кластеров и нужно попасть на 14-ый(отсчёт с нуля):

|00|1297|8|
|08|4932|4|
|12|6321|4|

Из этой таблицы извлекается третья запись и считается отступ(14-12=2), т.о. нужный нам кластер находится под номером 6323.

Я имел в виду загружать весь лог в таблицу БД каким-нибудь Job'ом, исполняющимся периодически. Структурированные текстовые файлы вроде можно так загружать какими-то простыми командами. Может, это и бред — рассуждаю почти наугад.

The gray Cardinal,

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

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

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

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

Я имел в виду загружать весь лог в таблицу БД каким-нибудь Job'ом, исполняющимся периодически. Структурированные текстовые файлы вроде можно так загружать какими-то простыми командами. Может, это и бред — рассуждаю почти наугад.

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

Dmitrii,

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

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

если нужна конкретика - то я имею ввиду как раз лог MS SQL сервера.
Кто в курсе - файл ERRORLOG.

Новая версия файла образуется при перезагрузке сервера - вот такой вот "странный способ ведения лога".
А так как перезагрузка только в крайнем случае - то копится он несколько месяцев.

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

Спасибо за предложенные варианты.
Буду дальше пробовать.

На самом деле "чтение с конца" - реально с конца, а не иммитация разными способами - не такая уж и очевидная вещь.

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

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

Так вот, лог-файл немерянный, управлять его размером я не могу, а читать ну о-о-о-о-чень хочется именно с конца.

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