Quote (MACTEP1)
Оно мне надо - понимать, КАК работает эта система?
Надо. Объясняю:
В доисторическом исходном UNIX и во всех (наверное) его клонах и потомках было весьма интересное отношение к файлам.
Понятие "файл" объединяло в себе две где-то разные сущности:
1 сущность - собственно данные
2 сущность - индексный дескриптор (он же - описатель файла, бурж. "inode")
Собственно данные - это само содержимое файла, разбросанное по тому накопителю, где "находится" файл.
В дескрипторе содержится информация о том, где же находятся "Собственно данные" и как всю эту прорву байт называть (иными словами, в дескрипторе находятся адреса блоков с содержимым файла, имя "файла", права доступа к "файлу" и что-то еще).
Отсюда следует три интересных вывода:
1. "Файл" = "Дескриптор + Данные"
2. Понятие "Имя файла" относится к дескриптору и к данным не имеет вообще никакого отношения (грубо: на дорожках и жесткого диске нет специального участка, в котором написано, что следующие 10 секторов дорожки относятся к файлу "Вася купил себе самосвал.jpg")
3. На одни и те же данные могут ссылаться несколько дескрипторов (их называют "жесткими ссылками"). (Помедитируйте над этим 
)
Чем это грозит?
Это грозит тем, что в системе возможно существование нескольких разных файлов, содержимое которых абсолютно идентично.
Представим ситуацию: Есть два файла, у которых дескрипторы ссылаются на одни и те же данные.
УглУбим концентрацию и подумаем: Что будет, если в один из этих файлов внести изменения?
Ответ: изменения произойдут и в другом файле.
Показываю на примере (осторожно, командная строка 
)
1. Текущая дата:
Code
netadmin@web:~$ date
Чтв Май 12 02:10:59 MSD 2011
2. Создаем первый файл.
Code
netadmin@web:~$ echo "Эта строка записана в первый файл" > ./1.txt
Появился ли файл:
Code
netadmin@web:~$ ls -l
итого 2715
-rw-r--r-- 1 netadmin netadmin 62 Май 12 02:11 1.txt
Его содержимое:
Code
netadmin@web:~$ cat ./1.txt
Эта строка записана в первый файл
3 Создаем жесткую ссылку на первый файл:
Code
netadmin@web:~$ ln ./1.txt ./2.txt
Появилась ли ссылка:
Code
netadmin@web:~$ ls -l
итого 2716
-rw-r--r-- 2 netadmin netadmin 62 Май 12 02:11 1.txt
-rw-r--r-- 2 netadmin netadmin 62 Май 12 02:11 2.txt
Его содержимое:
Code
netadmin@web:~$ cat ./2.txt
Эта строка записана в первый файл
Собственно, то самое разделение на дескриптор и данные.
Все выглядит, будто создано два разных файла, а содержимое у них одно и то же. 4. Смотрим на атрибуты файлов:
Первый файл:
Code
netadmin@web:~$ stat ./1.txt
File: «./1.txt»
Size: 62 Blocks: 2 IO Block: 1024 обычный файл
Device: 805h/2053d Inode: 83651 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 1000/netadmin) Gid: ( 1000/netadmin)
Access: 2011-05-12 02:14:10.000000000 +0400
Modify: 2011-05-12 02:11:43.000000000 +0400
Change: 2011-05-12 02:13:19.000000000 +0400
Второй файл:
Code
netadmin@web:~$ stat ./2.txt
File: «./2.txt»
Size: 62 Blocks: 2 IO Block: 1024 обычный файл
Device: 805h/2053d Inode: 83651 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 1000/netadmin) Gid: ( 1000/netadmin)
Access: 2011-05-12 02:14:10.000000000 +0400
Modify: 2011-05-12 02:11:43.000000000 +0400
Change: 2011-05-12 02:13:19.000000000 +0400
Как мы видим, разницы никакой. Теперь делаем подъем с переворотом:
Повторим текущую дату:
Code
netadmin@web:~$ date
Чтв Май 12 02:17:08 MSD 2011
5. Изменим содержимое второго файла:
Code
netadmin@web:~$ echo "Эта строка записана во второй файл" > ./2.txt
6 Читаем содержимое второго файла:
Code
netadmin@web:~$ cat ./2.txt
Эта строка записана во второй файл
все хорошо. 7. Теперь читаем содержимое первого файла:
Code
netadmin@web:~$ cat ./1.txt
Эта строка записана во второй файл
... медитируем. 
8. Смотрим атрибуты файлов:
Code
netadmin@web:~$ stat ./1.txt
File: «./1.txt»
Size: 64 Blocks: 2 IO Block: 1024 обычный файл
Device: 805h/2053d Inode: 83651 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 1000/netadmin) Gid: ( 1000/netadmin)
Access: 2011-05-12 02:18:56.000000000 +0400
Modify: 2011-05-12 02:18:26.000000000 +0400
Change: 2011-05-12 02:18:26.000000000 +0400
netadmin@web:~$ stat ./2.txt
File: «./2.txt»
Size: 64 Blocks: 2 IO Block: 1024 обычный файл
Device: 805h/2053d Inode: 83651 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 1000/netadmin) Gid: ( 1000/netadmin)
Access: 2011-05-12 02:18:56.000000000 +0400
Modify: 2011-05-12 02:18:26.000000000 +0400
Change: 2011-05-12 02:18:26.000000000 +0400
Никакой разницы. 9. Теперь смотрим вывод ls
Code
netadmin@web:~$ ls -l | grep 'txt'
-rw-r--r-- 2 netadmin netadmin 64 Май 12 02:18 1.txt
-rw-r--r-- 2 netadmin netadmin 64 Май 12 02:18 2.txt
Тоже никакой разницы. ВНИМАНИЕ ВОПРОС:
Если бы в юниксах существовало такое понятие, как "Дата и время создания файла", то что должна была вывести команда ls?
Мы создали два разных файла, ссылающиеся на одни и те же участки на диске. Что считать "временем создания файла"? Время, когда на эти данные начал ссылаться дескриптор первого файла или второго?
Если взять за основу время создания первого дескриптора, то какую дату принимать за время создания второго файла, если я создам жесткую ссылку на первый файл (т.е., тот самый "второй файл") через через 5 лет?
Если же, создав второй файл, его "дату создания" приписать первому, то получится, что первый файл внезапно помолодел.
Вы спросите: если дескрипторы независимы, а данные не содержат вообще никакой информации о дате своего создания, изменения и прочего мусора, почему бы не прописать в дескрипторе каждого файла дату создания и изменения этих дескрипторов, т.е., первый файл будет иметь свою дату создания и изменения, второй - свою.
Тогда получится очень интересная ситуация:
Вы создаете файл 1.txt, что-то в него записываете.
Через год создаете жесткую ссылку на этот файлю
Еще через полгода правите второй файл.
Еще через год вы забываете о том, кто кому там ссылка и что вообще происходит. Смотрите дату создания первого файла: "Ага, 2011 год", смотрите дату создания второго файла: "Ага, 2012 год. Первый файл старше на год. Там старые данные, там старый бэкап моего сервера. Восстановлюсь-ка я с него.".
Смотрите содержимое первого файла, а там не старый бэкап, а то же, что и во втором файле.
"Облом-с." (с)
p.s: В NTFS также разделяют содержимое файла и его дескриптор.
p.s2: Каждый файл в юникс-системах является жесткой ссылкой. Даже в том случае, если ни в одном другом дескрипторе нет ссылки на его данные. Т.е., нет какого-то "первого дескриптора" или "главного дескриптора", который распоряжается данными. Все жесткие ссылки равноправны.
Медитация на тему удаления файлов в юникс-системах остается в качестве домашнего задания 
)
