Файл /etc/passwd просто сопоставляет символические имена пользователей с реальным идентификатором пользователя. Если вы намеренно создаете два символических имени, которые сопоставляются с одним идентификатором пользователя, это позволит вам.
Это не значит, что это действительно хорошая идея. Некоторые люди, возможно, нашли очень конкретные случаи использования, когда они могут воспользоваться этой функцией, но в целом вы не должны этого делать.
Linux (и другие UNIX) считают, что администратор знает, делает. Если вы скажете ему сделать что-то глупое, то это ваша собственная ошибка, во многом так же, как если бы вы сказали своей машине ехать по скале, вы не можете пойти к производителям и спросить, почему автомобиль разрешил вам это сделать. [ ! d2]
Ну, это довольно странно. Возьмем исполняемый файл с именем / usr / local / bin / whoopdeedoo. Это только ссылка на так называемый inode (базовая структура файлов в Unix Filesystems).
Теперь, когда вы удаляете или перемещаете файл / usr / local / whoopdeedoo, единственное, что перемещается (или вытирается), является ссылкой на индексный дескриптор. Сам десор остается неизменным. Это, по сути, это.
Я должен проверить это, но я считаю, что вы можете это сделать и в файловых системах Mac OS X.
Windows использует другой подход. Зачем? Кто знает...? Я не знаком с внутренними компонентами NTFS. Теоретически, все файловые системы, использующие ссылки на внутренние структуры для имен файлов, должны быть в состоянии сделать это.
Допустим, я слишком упрощен, но прочитайте раздел «Последствия» в Википедии, который делает намного лучшую работу чем я.
Одна вещь, которая кажется отсутствующей во всех других ответах, заключается в следующем: когда файл открывается, а программа имеет открытый файловый дескриптор, файл не будет удален из системы до тех пор, пока дескриптор файла не будет закрыт.
] Попытки удалить указанный inode будут задерживаться до тех пор, пока файл не будет закрыт: переименование в той же или другой файловой системе не может повлиять на открытый файл, независимо от поведения переименования, или явно удалять или перезаписывать файл с новым. Единственный способ, с помощью которого вы можете испортить файл, - это явно открыть его inode и беспорядок с содержимым, а не операциями в каталоге, такими как переименование / удаление файла.
Кроме того, когда ядро выполняет файл сохраняет ссылку на исполняемый файл, и это снова предотвратит любую его модификацию во время выполнения.
Итак, в конце, даже если это похоже на то, что вы можете удалить / переместить файлы, которые составляют запущенная программа, на самом деле содержимое этих файлов хранится в памяти до тех пор, пока программа не закончится.
В файловой системе Linux при перемещении файла, если он не пересекает границы файловой системы (чтение: остается на одном диске / разделе), все, что вы меняете, является inode .. (родительский каталог) к новому местоположению. Фактические данные вообще не перемещаются на диске, просто указатель, чтобы файловая система знала, где его найти.
Вот почему операции перемещения настолько быстрые и вероятные, почему нет проблемы с перемещением как вы фактически не перемещаете программу.
Это возможно, потому что перемещение программы не влияет на запущенные процессы, запущенные при ее запуске.
После запуска программы его биты на диске защищены от перезаписи, но нет необходимости защищать файл, который нужно переименовать, перемещать в другое место в той же файловой системе, что эквивалентно переименованию файла или перемещению в другую файловую систему, что эквивалентно копированию файла в другом месте и удалению его.
Удаление файла, который используется, либо из-за того, что на нем есть открытый файловый дескриптор, либо из-за того, что процесс его выполняет, он не удаляет данные файла, на который ссылается файл inode, но удаляет только directory, т.е. путь, из которого может быть достигнут индекс.
Обратите внимание, что запуск программы не загружает все сразу в (физическую) память. Напротив, загружается только строгий минимум, необходимый для запуска процесса. Затем требуемые страницы загружаются по требованию в течение всей жизни процесса. это называется поисковым вызовом. Если есть нехватка оперативной памяти, ОС может освободить RAM, хранящую эти страницы, поэтому вполне возможно, что процесс может загружать несколько раз одну и ту же страницу из исполняемого inode.
Причина, по которой это было возможно, из-за невозможности использования Windows из-за того факта, что базовая файловая система (FAT) не поддерживает разделяемую концепцию записей в каталоге и inodes. Это ограничение больше не присутствовало в NTFS, но дизайн ОС был сохранен в течение длительного времени, что привело к нежелательному ограничению необходимости перезагрузки при установке новой версии двоичного файла, что больше не имеет отношения к последним версиям Windows.
В основном, в Unix и его ilk, имя файла (включая путь к каталогу, ведущий к нему) используется для связывания / поиска файла при его открытии (выполнение файла является одним из способов его открытия). После этого момента идентификатор файла (через его «inode») устанавливается и больше не подвергается сомнению. Вы можете удалить файл, переименовать его, изменить его разрешения. Пока какой-либо процесс или путь к файлу имеют дескриптор этого файла / inode, он будет придерживаться, точно так же, как труба между процессами (фактически, в исторической UNIX труба была безымянным inode с размером, который только что установлен в
Если у вас есть просмотрщик PDF в PDF-файле, вы можете удалить этот файл и открыть новый с тем же именем , и пока старый зритель открыт, он все равно будет нормально обращаться к старому файлу (если он не будет активно следить за файловой системой, чтобы заметить, когда файл исчезает под своим первоначальным именем).
Программы, требующие временные файлы могут просто открыть такой файл под каким-то именем, а затем открыть удалить его (или, скорее, его запись в каталог), пока он еще открыт. После этого файл больше не доступен по имени, но любые процессы, имеющие открытый файловый дескриптор файла, могут получить к нему доступ, и если после этого произойдет непредвиденный выход из программы, файл будет удален и хранилище будет автоматически исправлено. [ ! d4]
Таким образом, путь к файлу не является свойством самого файла (на самом деле жесткие ссылки могут содержать несколько разных путей) и необходимы только для его открытия, а не для непрерывного доступа процессами, которые уже имеют его открыт.