@kravam

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

0

@Puporev

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

0

@Monte-Cristo

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

0

@skvor

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

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

0

Evg

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

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

0

@skvor

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

0

@kravam

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

0

@Puporev

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

0

Vourhey

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

0

@odip

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

0

@-=ЮрА=-

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

0

@Ethereal

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

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

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

- Существовали когда-то операционные системы, в которых длина файла в байтах не хранилась в файловой системе нигде. Хранилась только длина в блоках (в привычной Вам терминологии - в секторах диска). Пример такой ОС - 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

@gazlan

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

1

Evg

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

0

@-=ЮрА=-

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


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

0

Evg

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

0