Жесткая ссылка/индексный дескриптор файла (Что есть такое, как пользоваться? ))

[Yaros]

А вот здесь можно поконкретнее? Оно создается только на момент открытия файла? Так как-же тогда с ним чего-то ассоциируется на постоянной основе? (имя файла-жесткая ссылка к дескриптору). Или Вы говорите не об "индексном дескрипторе файла", о котором я спрашивала относительно ЖС, а о чем-то ином? Или же Файловый дескриптор при открытии файла возникает и при имении и отсутствии инода (в этом случае он как-бы равен ему, ?), возникает в любом случае, а в Википедии определение ЖС дается в частном случае имения инода? Или как? Опять чего-то запуталась )

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

Код: Выделить всё

$ ls -l
итого 0
-rw-r--r-- 1 yaroslav yaroslav 0 Апр  9 12:59 example.f
$ ln example.f sec_example.f
$ ls -l
итого 0
-rw-r--r-- 2 yaroslav yaroslav 0 Апр  9 12:59 example.f
-rw-r--r-- 2 yaroslav yaroslav 0 Апр  9 12:59 sec_example.f
$ ls -li
итого 0
1155124 -rw-r--r-- 2 yaroslav yaroslav 0 Апр  9 12:59 example.f
1155124 -rw-r--r-- 2 yaroslav yaroslav 0 Апр  9 12:59 sec_example.f

Опция -li указывает inode перед правами - как видите, он одинаков для обоих файлов (которые на самом деле один файл, но с разными именами). В man ln хорошо написано:

Жесткая ссылка является всего лишь именем какого-либо файла. (Таким образом, файл может иметь несколько имен. Он будет удален с диска только тогда, когда будет удалено последнее из его имен. Количество имен, которые имеет файл, показывает команда ls(1). Нет такого понятия, как настоящее имя: все имена имеют одинаковый статус.

Пусть меня поправят, если я в чем-то не прав.

[Experementator]

Зато есть такой фокус:

Эмм... Занятно. А чем это объясняется?.. ls и du по-разному подсчитывают объём данных?..

[Frank]

Зато есть такой фокус:

Эмм... Занятно. А чем это объясняется?.. ls и du по-разному подсчитывают объём данных?..

Конечно. Размер файла и занимаемое место - две разные вещи. Очень редко они совпадают; для большинства файлов занимаемое место чуть больше размера файла (т.н. остатки кластеров пропадают "впустую"), а для некоторых - наоборот: sparce files (разреженные файлы) или сжатие на лету (знакомое многим по NTFS).

[Experementator]

То есть получается, что в приведённом eddy'ом примере мы имеем файл, который имеет размер 64Гб, хотя на диске занимает 65Мб... Ё-мое!.. Где прикол?..

[eddy]

Конечно. Размер файла и занимаемое место - две разные вещи.

Ага. Вот как я это сделал:

Код: Выделить всё

#define _FILE_OFFSET_BITS 64
#define _LARGEFILE64_SOURCE
#include <stdio.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/types.h>
#include <unistd.h>
#include <linux/unistd.h>
main(){
    int f = open("tmp", O_WRONLY|O_CREAT|O_LARGEFILE, 0666);
    char a = 'a';
    lseek(f, 0xFFFFFFFFELL, SEEK_SET);
    write(f, &a, 1);
    close(f);
}

Ё-мое!.. Где прикол?..

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

[Experementator]

То есть место выделено, но не занято?.. Как-то так получается...

[drBatty]

Можно в первом приближении считать, что жёсткая ссылка - это и есть имя файла.

Именно что не в первом приближении, а так оно и есть. Имя файла - это и есть жёсткая ссылка на него.

... это не факт, а так оно и есть на самом деле...

вы не правы: имя файла - это строка символов (точнее последовательность байт, среди которых не может быть \x00).

Файл может иметь несколько имён, и если имён у файла более одного, то такой файл называется жёсткой ссылкой (ага. сам на себя. В действительности никто ни на кого не ссылается - это один и тот-же файл. В заблуждение вводит английское слово link, и его русский перевод - "ссылка", на самом деле, это никакая не ссылка, а просто разные ярлычки на одно и тоже).

Сами имена хранятся в особых файлах - они называются "каталоги". Это специализированные базы данных на основе 2-3 деревьев, в которых хранится соответствие между именами файлов, и номерами их inode (инодов). Сами иноды хранятся совсем в другом месте - место для инодов зарезервировано и не меняется никогда (с момента создания ФС). В инодах хранятся все атрибуты файлов (кроме имён конечно), а также ссылки на блоки с данными (или сами данные, если их мало).

Сколько файлов - столько и айнодов.

нет. структур для inode намного больше чем файлов, просто не все из них используются. Путаница возникает потому, что одним термином (inode) называют одновременно и структуру данных с атрибутами, и номер этой структуры. В каталогах хранится соответствие имени и номера инода.

Эмм... Занятно. А чем это объясняется?.. ls и du по-разному подсчитывают объём данных?..

ls показывает размер файла. Однако, блоки в которых все байты равны нулю на диске не хранятся. Потому файлы, в которых много нулей занимают намного меньше места на диске:

Код: Выделить всё

drb@localhost:~/scripts$ du -h /var/aMule_Temp/024.part
1,4G    /var/aMule_Temp/024.part
drb@localhost:~/scripts$ ll -h /var/aMule_Temp/024.part
-rw-r--r-- 1 amule users 2,2G 2010-04-09 13:13 /var/aMule_Temp/024.part

вот я закачиваю файл в 2.2Г, но закачал ещё только 1.4Г. Потому он и занимает всего 1.4Г.

ЗЫЖ всё вышесказанное относится к EXT2,3,4

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

можно было не парится с Си, а скопировать устройство /dev/zero

[eddy]

можно было не парится с Си, а скопировать устройство /dev/zero

Вообще-то, нули занимают место на диске:

Код: Выделить всё

[09.04 15:35 ~/tmp]
dd if=/dev/zero of=tst bs=1024 count=1024
1024+0 записей считано
1024+0 записей написано
 скопировано 1048576 байт (1,0 MB), 0,0221383 c, 47,4 MB/c
[09.04 15:40 ~/tmp]
du tst
1,1M    tst
[09.04 15:40 ~/tmp]
ll tst
-rw-r--r-- 1 eddy eddy 1048576 2010-04-09 15:40 tst

И вы неправы насчет

Однако, блоки в которых все байты равны нулю на диске не хранятся

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

[Experementator]

ls показывает размер файла. Однако, блоки в которых все байты равны нулю на диске не хранятся. Потому файлы, в которых много нулей занимают намного меньше места на диске:

Всё, спасибо большое, разобрался. :)

[drBatty]

Вообще-то, нули занимают место на диске:

а теперь скопируйте ваш файл командой cp (кстати, в мане про это есть).

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

я нее сказал "всегда". Блок с нулями может и хранится, и не хранится на диске. И соответственно как занимать, так и не занимать на нём место.
Впрочем, вот цитата:

By default, sparse SOURCE files are detected by a crude heuristic and the corresponding DEST file is made
sparse as well. That is the behavior selected by --sparse=auto. Specify --sparse=always to create a
sparse DEST file whenever the SOURCE file contains a long enough sequence of zero bytes. Use
--sparse=never to inhibit creation of sparse files.

т.е. разряжённые файлы можно создавать не только fseek, но и просто копированием любых других.

[eddy]

а теперь скопируйте ваш файл командой cp (кстати, в мане про это есть).

Копировался долго, но получилось то же самое.

[watashiwa_daredeska]

если имён у файла более одного, то такой файл называется жёсткой ссылкой

Файл жёсткой ссылкой не называется. Это совершенно точно. Жёсткая ссылка — это именно ссылка, из каталога на инод. И она жёсткая ссылка, даже если она одна.

[QWERTYASDF]

Спасибо всем ответчикам, что-то еще чуть больше прояснилось ) Но в то-же время еще и чуть больше запуталось )))
А вот что такое вообще "файл"? "В виндоус" учат, что файл есть поименованная область на носителе информации, к каждому кусочку (кластеру/сектору) которой можно потом обращаться при помощи системы адресации фс. В Юникс же "файл - это все" (ни больше ни меньше..) т.е. файл - это любой ресурс (аппаратный и/или программный),доступный к обращению по определенному адресу. Тут у меня напрашивается несколько главных вопросов:
1. Файл, как "периметр" области на носителе, в которой потенциально могут находиться какие-либо данные т.е. как объект файловой системы - концептуально первичнее понятия "файл-это все", или это вообще две независимые друг от друга концепции? Видимо первичнее
2. В случае "юникс-файла", где все-таки заложена граница между ресурсами-файлами и ресурсами-не файлами? ) Ведь все-таки нельзя ну абсолютно ВСЕ ресурсы т.е. объекты системы всех уровней абстракности понимать как файлы, путаница какая-то тогда ведь...) Все апи ОС, все иноды, дескрипторы и т.п. - тоже тогда попадают под определение файла...)

если имён у файла более одного, то такой файл называется жёсткой ссылкой

Файл жёсткой ссылкой не называется. Это совершенно точно. Жёсткая ссылка — это именно ссылка, из каталога на инод. И она жёсткая ссылка, даже если она одна.

А почему у меня в файловом браузере ЭТО показывается (и учитывается даже), как файл? А если показывается/учитывается как файл, так что-же еще нужно для того, чтобы ЭТО называть файлом?

[drBatty]

Копировался долго, но получилось то же самое.

странно. хотя в инфо и написано, что в cp применён очень простой, тупой, и быстрый алгоритм...

Файл жёсткой ссылкой не называется. Это совершенно точно. Жёсткая ссылка — это именно ссылка, из каталога на инод. И она жёсткая ссылка, даже если она одна.

дык в таком случае все файлы - суть жёсткие ссылки.
ну за исключением безымянных вроде pipe.
Давайте разберёмся с терминологией - что такое по вашему "ссылка"? А то я с тем же успехом буду называть клопов бегемотами.

И как понять - "из каталога на инод"? В каталоге записан номер структуры с атрибутами файла. В принципе, номер структуры можно считать "ссылкой", а саму структуру можно считать "инодом". Если я правильно вас понимаю, конечно...

[t.t]

если имён у файла более одного, то такой файл называется жёсткой ссылкой

Файл жёсткой ссылкой не называется. Это совершенно точно. Жёсткая ссылка — это именно ссылка, из каталога на инод. И она жёсткая ссылка, даже если она одна.

Добавлю: скажем, последовательность команд touch 1; ln 1 2; rm 1 по конечному результату совершенно аналогична команде touch 2.

[eddy]

Вообще-то, когда вы обращаетесь к какому бы то ни было файлу, что делать дальше, решает операционная система, и генерирует нужный сисвызов. Если вы пытаетесь прочитать файл на диске, активируется сисвызов read, если обращаетесь к /dev/ttySx - сисвызов, работающий с RS-232 и т.п. Для пользователя все выполняется прозрачно, и это очень удобно.

[QWERTYASDF]

Вообще-то, когда вы обращаетесь к какому бы то ни было файлу, что делать дальше, решает операционная система, и генерирует нужный сисвызов. Если вы пытаетесь прочитать файл на диске, активируется сисвызов read, если обращаетесь к /dev/ttySx - сисвызов, работающий с RS-232 и т.п. Для пользователя все выполняется прозрачно, и это очень удобно.

Т.е. "файл" - это можно сказать, любой доступный к обращению пользователя (!) ресурс (а внутренняя механика пользователя не касается). Что уже концептуально является делом не пользователя а админа/програмера - это уже не файл. Можно так сказать?

[drBatty]

1. Файл, как "периметр" области на носителе, в которой потенциально могут находиться какие-либо данные т.е. как объект файловой системы - концептуально первичнее понятия "файл-это все", или это вообще две независимые друг от друга концепции? Видимо первичнее

это вопрос из области философии ИМХО. Я знаю как устроенна ФС EXT3, а вопросом "первичности" не интересовался.

А вот что такое вообще "файл"? "В виндоус" учат, что файл есть поименованная область на носителе информации

не. в Linux понятие "имя" оторвано от файла - имя хранится в каталоге, и его может и не быть. А может быть много имён.

На самом деле, при создании ФС выделяется несколько (сотни тысяч) структур данных, в 128байт (ЕМНИП), в которых и хранится информация о файлах. Причём в этих 128и байтах хранится вся информация, кроме имени, и (обычно) содержимого файла. Где находится эти структуры (иноды) записано в суперблоке (и в его копиях, коих несколько десятков). Они (структуры) никогда не перемещаются, и их число никогда не меняется.

2. В случае "юникс-файла", где все-таки заложена граница между ресурсами-файлами и ресурсами-не файлами? ) Ведь все-таки нельзя ну абсолютно ВСЕ ресурсы т.е. объекты системы всех уровней абстракности понимать как файлы, путаница какая-то тогда ведь...) Все апи ОС, все иноды, дескрипторы и т.п. - тоже тогда попадают под определение файла...)

"абсолютно всё" нельзя по другим причинам - например ВСЕ предметы можно назвать словами. Причём существительными в именительном падеже. А зачем в русском языке глаголы или междометия? Какой предмет нельзя назвать существительным? Никакой. Тем не менее, среди слов есть не только существительные. Так и в UNIX, хоть и "всё - файлы", однако есть и не только файлы. Есть например процессы, или сетевые интерфейсы, которые - не файлы. Не вижу противоречия.

Добавлю: скажем, последовательность команд touch 1; ln 1 2; rm 1 по конечному результату совершенно аналогична команде touch 2.

ну и что? команда rm вовсе не всегда удаляет файл, сначала она удаляет имя из каталога, и если у файла больше нет имён, то тогда его уничтожает. В данном случае у файла имя не последнее.

Что уже концептуально является делом не пользователя а админа/програмера - это уже не файл. Можно так сказать?

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

Добавлю: скажем, последовательность команд touch 1; ln 1 2; rm 1 по конечному результату совершенно аналогична команде touch 2.

ага. по конечному - да. но по действию, ваши команды совершенно аналогичны mv 1 2, т.е. вы переименовали файл 1, в файл 2. И именно так, кстати, и работает команда переименования - создаёт хардлинк, а потом стирает файл.

[eddy]

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

Файлы, кстати, тоже нужны. Например, в одной программе мне нужно контролировать, чтобы одновременно не было запущено несколько процессов. При запуске программа просматривает директорию /proc на предмет работы одноименных процессов (т.е. делает аналог pgrep), потом каждому найденному процессу (кроме себя, конечно) посылается сигнал (SIGKILL или SIGTERM - смотря как надо убить эти процессы).
Так что и псевдофайловая система /proc тоже используется довольно часто.

[eddy]

Кстати, чтобы уж совсем запутать QWERTYASDF: многие программы, чтобы "не мусорить" временными файлами сразу после открывания такого файла делают ему unlink. В итоге файл для других процессов как бы существует, но место на диске занимает.
Если такая программа зациклится и будет пытаться что-то до бесконечности писать в такой временный файл, получится ситуация, когда df покажет нам 0 свободного для доступа пользователя места, но find'ом файл мы найти не сможем. Придется либо убивать все подозрительные процессы (если этот процесс не самоликвидируется из-за ошибки записи), либо перезагружаться, либо долго искать lsof'ом, какие процессы пишут в несуществующие файлы.

[QWERTYASDF]

1. Файл, как "периметр" области на носителе, в которой потенциально могут находиться какие-либо данные т.е. как объект файловой системы - концептуально первичнее понятия "файл-это все", или это вообще две независимые друг от друга концепции? Видимо первичнее

это вопрос из области философии ИМХО. Я знаю как устроенна ФС EXT3, а вопросом "первичности" не интересовался.

2. В случае "юникс-файла", где все-таки заложена граница между ресурсами-файлами и ресурсами-не файлами? ) Ведь все-таки нельзя ну абсолютно ВСЕ ресурсы т.е. объекты системы всех уровней абстракности понимать как файлы, путаница какая-то тогда ведь...) Все апи ОС, все иноды, дескрипторы и т.п. - тоже тогда попадают под определение файла...)

"абсолютно всё" нельзя по другим причинам - например ВСЕ предметы можно назвать словами. Причём существительными в именительном падеже. А зачем в русском языке глаголы или междометия? Какой предмет нельзя назвать существительным? Никакой. Тем не менее, среди слов есть не только существительные. Так и в UNIX, хоть и "всё - файлы", однако есть и не только файлы. Есть например процессы, или сетевые интерфейсы, которые - не файлы. Не вижу противоречия.

Нет. Философия тут хоть конечно играет далеко не последнюю роль, но все-равно это вопрос конкретной сформулированной концепции т.к. с позиции чистой философии обычное дело доказать почему кирпич все-таки на самом деле является слоном, а виндоус - линуксом. Т.е. с позиции чистой философии можно утверждать что угодно о чем угодно, но здесь мы все-таки имеем дело не с чистой философией, а с научной дисциплиной.
Кто/что в общем определяет когда употребляется существительное а не глагол, или наоборот - филология/лингвистика, их конкретные концепты.

Так и в UNIX, хоть и "всё - файлы", однако есть и не только файлы

Замечательно! А каким образом определяется когда НЕЧТО есть файл, а когда оно все-таки процесс там или интерфейс, учитывая то, что это НЕЧТО потенциально в разных ситуациях может быть и тем и тем? )) Так что все-таки такое файл? Точная формулировка какая!? Вы же не скажете, когда спросят по поводу того, что есть такое существительное - что, мол все предметы при желании можно назвать существительным, но тем не менее, среди слов есть не только существительные (с)
В Виндоус например совершенно точно (вне зависимости от конкретного устройства конкретной фс) ясно, что файл есть некоторая помеченная область на носителе, исп. для хранения данных и/или такая метка + сами данные, а фс есть принцип организации файлов для работы с ними (это не камень в огород Линукса, а просто факт).

Что уже концептуально является делом не пользователя а админа/програмера - это уже не файл. Можно так сказать?

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

А почему они не файлы? Если "файл - это все" т.е. любой более или менее абстрактный объект, которому на момент существования выделяется адрес в некоем адресном пространстве, и к которому по этому адресу можно обращаться с той или иной "просьбой" - то решительно не понимаю, почему например программный процесс есть исключение...
Хотя если исходить точно из Вашего ответа, как-раз и получается подверждение моему предположению - админ работает с процессами, которые не файлы...Тогда файлы могут являться чисто пользовательским понятием. Не вижу противоречия =)

[drBatty]

В итоге файл для других процессов как бы существует, но место на диске занимает.

как бы НЕ существует?

[eddy]

А почему они не файлы? Если "файл - это все" т.е. любой более или менее абстрактный объект, которому на момент существования выделяется адрес в некоем адресном пространстве, и к которому по этому адресу можно обращаться с той или иной "просьбой" - то решительно не понимаю, почему например программный процесс есть исключение...

Я уже говорил про псевдофайловую систему proc. Загляните в директорию /proc. В ней есть поддиректории, по одной на каждый процесс (имя директории - pid процесса). Здесь вы можете посмотреть информацию о стеках процессов, заглянуть в область памяти, которую процесс занимает. В общем, там много любопытной информации. Кстати, всякие руткиты, собирающие пароли, часто пользуются именно /proc, в надежде на race condition - когда пароль на некоторое время появляется в незашифрованном виде в памяти приложения.

А каким образом определяется когда НЕЧТО есть файл, а когда оно все-таки процесс там или интерфейс, учитывая то, что это НЕЧТО потенциально в разных ситуациях может быть и тем и тем?

И про это выше уже говорилось. Ядру вообще наплевать: файл или не файл, оно использует системные вызовы. А какой вызов надо сделать, определяют модули файловых систем и модули, работающие с устройствами. Например, когда вы пишете в /dev/dsp, активируется модуль, обслуживающий звуковую карту. Какой модуль за какую железяку отвечает, прописано в тех же псевдофайлах устройств.

как бы НЕ существует?

Ага, при быстрой печати встречаются очепятки и ашипки

[drBatty]

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

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

Так что все-таки такое файл? Точная формулировка какая!?

это довольно расплывчатое понятие, и в разных контекстах может означать что угодно. Не даром - "всё - файлы". Это удобно, т.к. с любым устройством, с любыми данными, и даже с любыми процессами можно работать как с файлами. Однако, на самом деле это всего-лишь - абстракция. Файл есть нечто, с чем можно работать. Обычно определены 3 действия:
1) чтение (снятие данных)
2) запись (управление устройством, например можно лампочками на клавиатуре помигать)
3) использование. для простых файлов это запуск как программа/скрипт, для каталогов - использование содержащихся в нём файлов (в т.ч. и подкаталогов), а для устройств - что-то ещё (если производителю это надо).
Это удобно, т.к. позволяет работать с совершенно разными сущностями одинаково, и даже подменять их (простой пример: замена принтера на файл, или ввода с клавиатуры в консоль на исполнение скрипта). Кроме того, можно ограничить пользователей так, что-бы они имели право только на некоторые действия.

Этой целостности и нет в виндовс, права и подмена устройств там осуществляется внешними костылями - если программист хочет выводить в файл а не на принтер, то ему либо придётся найти виртуальный "принтер", либо переписывать свою программу. В UNIX ничего переписывать не надо - просто отправьте вывод не на принтер, а на жёсткий диск (вместо /dev/lp0 на /dev/sda1).

А почему они не файлы? Если "файл - это все" т.е. любой более или менее абстрактный объект, которому на момент существования выделяется адрес в некоем адресном пространстве, и к которому по этому адресу можно обращаться с той или иной "просьбой" - то решительно не понимаю, почему например программный процесс есть исключение...

как уже выше сказано, процессы также отображаются на файловую систему в каталог /proc. Т.е. хоть это и не файлы, но с ними также можно работать как с файлами.

Хотя если исходить точно из Вашего ответа, как-раз и получается подверждение моему предположению - админ работает с процессами, которые не файлы...Тогда файлы могут являться чисто пользовательским понятием. Не вижу противоречия =)

не. файл - общее понятие. на самом деле, в венде также. просто это скрыто даже от программистов.

в надежде на race condition - когда пароль на некоторое время появляется в незашифрованном виде в памяти приложения

а пароль появляется только в некоторых программах, которые имеют SUID бит, и потому могут прятать (ИЧСХ прячут) свою память от о всех (кроме рута конечно).

[eddy]

в венде также. просто это скрыто даже от программистов.

Можно сказать "недокументированные особенности ОС от M$"

[Experementator]

К определению слова "файл".
ЕМНИП, "файл" - поток байтов, не более. Другой вопрос, что он может считаываться/записываться с харда, может с устройства, может с сети.

[drBatty]

Можно сказать "недокументированные особенности ОС от M$"

ага. всё там есть: и симлинки с хардлинками, и разряжённые файлы, и прочее... только этим всем управлять нормально нельзя. и не документировано - про те-же хардлинки в ддоке не сказано.

ЕМНИП, "файл" - поток байтов, не более.

ок. как ваше определение коррелирует с моей клавиатурой, которая - тоже файл?

[Experementator]

По-моему, более чем. Вы набираете текст на клавиатуре - ОС из соответствующего файла читает соответствующий поток байтов и обрабатывает его.

[QWERTYASDF]

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

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

Так что все-таки такое файл? Точная формулировка какая!?

это довольно расплывчатое понятие, и в разных контекстах может означать что угодно. Не даром - "всё - файлы". Это удобно, т.к. с любым устройством, с любыми данными, и даже с любыми процессами можно работать как с файлами. Однако, на самом деле это всего-лишь - абстракция. Файл есть нечто, с чем можно работать. Обычно определены 3 действия:
1) чтение (снятие данных)
2) запись (управление устройством, например можно лампочками на клавиатуре помигать)
3) использование. для простых файлов это запуск как программа/скрипт, для каталогов - использование содержащихся в нём файлов (в т.ч. и подкаталогов), а для устройств - что-то ещё (если производителю это надо).
Это удобно, т.к. позволяет работать с совершенно разными сущностями одинаково, и даже подменять их (простой пример: замена принтера на файл, или ввода с клавиатуры в консоль на исполнение скрипта). Кроме того, можно ограничить пользователей так, что-бы они имели право только на некоторые действия.

Этой целостности и нет в виндовс, права и подмена устройств там осуществляется внешними костылями - если программист хочет выводить в файл а не на принтер, то ему либо придётся найти виртуальный "принтер", либо переписывать свою программу. В UNIX ничего переписывать не надо - просто отправьте вывод не на принтер, а на жёсткий диск (вместо /dev/lp0 на /dev/sda1).

А почему они не файлы? Если "файл - это все" т.е. любой более или менее абстрактный объект, которому на момент существования выделяется адрес в некоем адресном пространстве, и к которому по этому адресу можно обращаться с той или иной "просьбой" - то решительно не понимаю, почему например программный процесс есть исключение...

как уже выше сказано, процессы также отображаются на файловую систему в каталог /proc. Т.е. хоть это и не файлы, но с ними также можно работать как с файлами.

Хотя если исходить точно из Вашего ответа, как-раз и получается подверждение моему предположению - админ работает с процессами, которые не файлы...Тогда файлы могут являться чисто пользовательским понятием. Не вижу противоречия =)

не. файл - общее понятие. на самом деле, в венде также. просто это скрыто даже от программистов.

Ок, значит слово "файл" имеет два основных определения:
1. Помеченная в соответствии с принципом конкретной фс, область данных на носителе
2. Абсолютно любой ресурс вычислительной системы, с которым при желании можно провести операции чтения/записи
Значит, например, какая-нибудь функция из набора апи может называться файлом, верно ведь?

К определению слова "файл".
ЕМНИП, "файл" - поток байтов, не более. Другой вопрос, что он может считаываться/записываться с харда, может с устройства, может с сети.

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

[Experementator]

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

Нну... Хорошо, переопределим. "Файл - это то, что при работе с ним представляет возможность считывать(записывать) с него поток данных."
Так лучше?.. :)