Существует ли EOF или это миф?

Собственно говоря, раньше у меня этот вопрос сомнений не вызывал. Есть файл- есть конец файла и умные проги автоматом добавляют в конец ff
...А тут что-то вплотную занялся функциями, работающими с файлами- нет EOFа в Hiewе.
Ну, то есть нет и всё. Я и текстовые файлы в Hiewе открывал и исполнимые- нет EOFа.
Но при программном считывании текстового файла в конце почему-то всё-таки выводится -1
...Так. А сама-то система как определяет, что найден конец файла? Допустим, в памяти расположен текстовый файл. И она его открывает, загружает то есть в оперативную память. Раньше понятно было- загружает посимвольно, пока не встретится ff. Встретился, она и его загрузила, всё на этом.
А если ff нет (а его ведь нет!)? Как же машина определит, что ЗАГРУЗКУ ФАЙЛА ПОРА ПРЕКРАЩАТЬ?
...В общем, я запутался. Помогите распутаться, пожалуйста.

0

Хорошо в Паскале. Обрабатываешь нажатие клавиш, нажимаешь Ctrl-Z, на экране 26.
Читаешь текстовый файл посимвольно
while c<>#26 do
..........................
считаешь и выводишь символы, символов на 1 больше чем количество введенных +по 2 невидимых на каждую строку, последним выводит такую стрелочку вправо, это и есть №26, или конец файла.

0

Сообщение от odip copy con file.txt При этом как закончить собственно набивание ? Нужно нажать Ctrl-Z + <ENTER>

ну создай файл таким путем. и обычным - через тот же notepad. и сравни двоичный код обоих. разницы ты не заметишь.

0

Puporev, "файлы" бывают разные. Клавиатура, это не совсем "файл", это поток ввода, и как любому потоку ему нужен подобный маркер. Пропускать или нет этот маркер в процесс читающий такой файл - дело системы и процесса. Но те файлы, у которых известна длинна и то, что записано на диске, в маркере конца не нуждаются, к тому же при этом пустые файлы требовали бы иметь этот маркер, а работа с бинарными данными вообще была бы противоестественной, т.к. пришлось бы мудрить с заменой числа 26 в в подобных файлах.

Представьте себе работу с файлом изображения, в котором возможно такое значение яркости канала.

0

skvor, с чем мы работаем, с файлом или потоком стандартного ввода - для пользовательского процесса это всё "файл". Вся работа накрыта интерфейсами типа feof (возвращает признак конца файла), fgetc (которая возвращает прочтённый байт или EOF) и куча прочего всего, которое работает через ОС (но никак не напрямую с файлом или устройством). А ОС уже сама подсунет этим процедурам что надо, при этом внутри ОС работа с настоящими файлами пойдёт по одной ветке, с устройствами по другой. Весь этот геморой сосредоточен в ОС, чтобы всё это было реализовано один раз, а для всех пользовательских задач и файлы и устройства и ещё чёрт-те что выглядело как "просто файл"

По крайней мере так в юниксах

0

Evg, так я об том и пишу! Только я думаю, лучше считать, что система делает обёртку для файла, делая из этого файла поток.
Тут ещё с терминологией забодаться десять раз. Но считать клавиатуру файлом нельзя - (1) её не переименовать, (2) у неё нет размера.
А то, что в DOS-е 26-ой код, так это можно списать на происки БГ.

0

...Рано написал выводы, прошу прощенья.

0

Все-таки иногда используется код 26. Вот из Вики.

Иногда конец текстового файла, особенно если в файловой системе не хранится информация о размере файла, также отмечается одним или более специальными знаками, известными как маркеры конца файла. В DOS и Microsoft Windows конец файла кодируется символом 0x1A, а в UNIX символ конца файла не употребляется.

0

Вот я почему-то сомневаюсь, что на вики имели ввиду NTFS-ные файлы. Если и на NTFS так, то это пипец...

Ты нажимаешь Ctrl+D.

который обрабатывается драйвером tty и все.

0

2Vourhey: Это и на NTFS так, но NTFS тут совершенно не при чем
Это внутри C-ных функций чтения файла. Если файл открыт в текстовом режиме и попался символ EOF, то считаем что произошла ситуация EOF (то есть достигнут конец файла).

0

Сообщение от Evg Машина (а точнее ОС) определяет просто - в файловой системе записан размер файла. А EOF - это не машинный термин, это для программистов. Т.е. можно было бы программные реализации по чтению из файла реализовывать в том виде, что ты можешь проверить, достигнут ли конец файла (сие означает, что текущая позиция смотрит за послелний байт файла), можешь прочесть один байт, если файл ещё не дошли до конца. Но так не совсем удобно. Удобнее сделать интерфейс для чтения байта, а по результату понять, смог ты считать байт или не смог, потому что достигнут конец файла. Причём интерфейсы такого рода имеют ти НЕ char, а более широкий, потому как нужно кодировать как 257 различных вариантов (256 различных байтов и признак конца файла). Значение EOF обычно равно -1, но в терминах int'а. Т.е. это 0xffffffff, но не 0xff. И фактически числовое значение EOF'а означает некий несуществующий байт, который кодирует ситуацию, когда достигли конца файла

Если посмотреть внимательно на структуру файловой системы то можно понять что файл - это цепочки кластеров и EOF миф который работает лишь для текстовых файлов, да и то помоему только для Си-шного потока записи feof(f). Если в файловой таблице не затереть кластеров то и конец файла не передвинем это также ясно как день. Даже если поставитм програмно символ EOF в текстовике то физических данных не уничтожим (просто feof будет сигнализировать о конце раньше)Затирать надо на уровне файловой системы!
Чтобы реально затереть данные в файле можно попробовать написать либо свой файловый парсер FAT или NTFS(что уже затруднительно) либо поюзать SetEndOfFile http://vsokovikov.narod.ru/New... offile.htm

0

Сообщение от Evg А почему же в юниксах (которые появилась раньше DOS'а) такого маразма не было. И как под виндами нормально копировать файл путём побайтного чтения? Или этот бубен с EOF'ом только в том случае, когда файл открывается в текстовом режиме (т.е. при окткрытии файла как "rb" всё будет работать как и у нормальных людей)?

Придется мне поднять этот старый топик, поскольку ни один человек правильный ответ не написал.

Во первых это не маразм. И копировать нормально никакой проблемы нет.

Правильный ответ :

- Существовали когда-то операционные системы, в которых длина файла в байтах не хранилась в файловой системе нигде. Хранилась только длина в блоках (в привычной Вам терминологии - в секторах диска). Пример такой ОС - RT-11. И, кстати, в сравнении с MS-DOS - это RT-11 нормальная.
- Ну а если в файловой системе хранится длина файла в блоках, то в текстовых файлах однозначно требуется управляющий символ, означающий конец текста. Потому-что в текстовом файле после окончания текста и до конца последнего блока файла будут нулевые или иные мусорные байты и надо как-то текст от них отделить. Но это символ НЕ конца ФАЙЛА ! А конца ТЕКСТА ! И этот символ - это именно Ctrl-Z с кодом 26.
- Когда файлы копируются их содержимое не учитывается никак. Копируются блоки файла и все.
- Когда файл выводится на терминал, а терминал печатает текст, то когда появляется символ Ctrl-Z вывод текста прекращается. Т.е. Ctrl-Z - это УПРАВЛЯЮЩИЙ СИМВОЛ ДЛЯ ТЕРМИНАЛА, ОЗНАЧАЮЩИЙ КОНЕЦ ТЕКСТА. Ну точно также, как Ctrl-M Ctrl-J = 13 10 для терминала означает возврат каретки и перевод строки. Терминал исполняет управляющие символы вместо их вывода и Ctrl-Z - один из них.

Добавлено через 10 минут
P.S. Хотя тут детали я уже позабыл. Или это команда TYPE перестает валить текст на терминал, когда встречает Ctrl-Z ? Факт, что Ctrl-Z как-то учитывается только в одном случае - когда выводится текст на терминал или принтер. И появление Ctrl-Z маркирует ситуацию "текст кончился, а файл, содержащий этот текст и из блоков состоящий, еще нет, но то, что там дальше в файле - это уже не текст"

Добавлено через 5 минут
P.P.S.
Короче Ctrl-Z - это не признак конца файла, а признак конца текста и он родился из инженерного решения длину файла в байтах в файловой системе на блочных устройствах не хранить, хранить только длину в блоках.

Добавлено через 6 минут
А вот что этот символ делает в MS-DOS (и по наследству в виндозной командной строке), где он не нужен (раз длина файла в байтах есть, то он не нужен) - этого я не знаю. Факт, что команда TYPE командной строки MS-DOS перестает выводить текст из файла, когда его встретит.

5

Сообщение от Ethereal что этот символ делает в MS-DOS

Маркирует конец текста. Долгое время, в текстовых файлах он рассматривался как обязательный. Если поднять старые (времен DOS 2.0) исходные тексты, .DBF-файлы итп, код 0x1A (Substitute) всюду был последним символом. Команда copy (без ключа /b) не будет копировать ничего, что стоит после этого символа итд.

1

Сообщение от Ethereal Но это символ НЕ конца ФАЙЛА ! А конца ТЕКСТА

Глубоко вникать в детали было лень, но по крайней мере это многое объясняет

0

Для конца файла EOF нет! Реально противно читать : когда падаёт файловая система, вы на HDD по EOF файлы ищете?а дифрагментация - т.е лежит себе такой кусок текстового файла(в 1кБ) пусть с принудительно записанным в него EOF(взяли и -1 записали а **ле), а в другом месте лежит другой кусок с началом(а между кусками 2 Гб места), а вы такие файловым read идёте себе такие по байтам пока ЕОФ не встретите... Вроде свиду гора понимающих людей, когда доходит до дела - на практике готовы обсуждать всякую чушь лишь бы не открыть простой учебник, да не посмотреть инфу. И я уверен скоро налетит туча людей поспорить что мол я зов не знаю и в таком роде=) Короче открываем "Записи каталога FAT" или просто берём и читаем немного о структуре файловых систем.


Добавлено через 10 минут

0

Сообщение от Ethereal Правильный ответ :

Кстати, если вернуться к первоначальному вопросу темы, символ с кодом 26 (который в старых системах явным образом обозначал конец текста) не имеет никакого отношения к Си'шному понятию EOF, который является логическим понятием, но не материальным

0