Как каталог является “специальным типом файла”?

Я думал, что следующее будет работать, но это оказалось ударом определенное решение. Оставляя этот ответ для ссылочной цели.

export PS1=' ! $( basename $PWD )'

Возможно, это требует обратных галочек вместо $( ) создать.

24
20.04.2015, 19:55
6 ответов

Многие сущности в *nix-стиле (и других) операционных системах считаются файлами или имеют определяющий файловый аспект, даже если они не обязательно представляют собой последовательность байт, хранящихся в файловой системе. Именно то, как реализуются каталоги, зависит от типа файловой системы, но обычно то, что они содержат, рассматриваясь как список, представляет собой последовательность хранимых байт, так что в этом смысле они не являются особенными.

Одним из способов определения того, что такое "файл" в контексте *nix, является то, что с ним связан дескриптор файла . Согласно статье Википедии, дескриптор файла

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

Другими словами, они относятся к различным видам ресурсов, с/на которые может быть прочитана/записана последовательность байтов, хотя источник/назначение этой последовательности не определено. Другими словами, "где" ресурс может быть чем угодно. Что определяет его, так это то, что он является каналом информации. Это часть того, почему иногда говорят, что в unix "все - это файл". Не стоит воспринимать это полностью буквально, но стоит серьезно подумать. В случае с каталогом эта информация относится к тому, что находится в каталоге, а на более низком, реализационном уровне, к тому, как найти ее внутри файловой системы.

Директории в этом смысле особенные, потому что в родном Си-коде они якобы не связаны с файловым дескриптором; POSIX API использует специальный тип дескриптора потока, DIR* . Однако, на самом деле, этот тип имеет дескриптор, лежащий в основе , который может быть получен. Дескрипторы управляются ядром и доступ к ним всегда включает в себя системные вызовы, следовательно, еще одним аспектом дескриптора является то, что он представляет собой канал, управляемый ядром ОС. Они имеют уникальные (для каждого процесса) номера, начинающиеся с 0, что обычно является дескриптором для стандартного входного потока .

19
27.01.2020, 19:40

Мой ответ - это простое воспоминание, но в 199x Vintage Unixes, из которых было много, каталоги были файлами, просто помечены «каталог» где-то на внутреннем inode.

Вы можете открыть каталог с чем-то вроде Open («.», O_RDONLY) и верните этот файловый дескриптор. Вы можете проанализировать содержимое, если вы взорвали через / usr / включают и нашли правильное определение структуры C. Я знаю, что я сделал это для SunoS 4.1.x Systems, файловой систему EFS SGI, и какие бы рабочие станции MIPS-процессора DEC имели для файловой системы, возможно, BSD4.2 FFS.

Это был плохой опыт. Стандартизация на виртуальном файловой системе слой является хорошей для мобильности, даже если каталоги больше не являются строгими файлами. Слои VFS позволяют экспериментировать с файловыми системами, где каталоги не являются файлами, такие как Reiserfs или NFS.

11
27.01.2020, 19:40

Справочник особенный в том, что он имеет «d» в своем режиме, сообщая файловую систему, что она должна интерпретировать его содержимое в виде списка других файлов, содержащихся в каталоге, а не регулярный файл, который является просто последовательностью Байты, которые будут прочитаны приложением. Это все.

3
27.01.2020, 19:40

В Unix Way of Doing Things: все - это файл.

Каталог - это один (из многих) тип специального файла. Она не содержит данных. Вместо этого, он содержит указатели на все файлы, которые содержатся в каталоге.

Другие типы специальных файлов:

  • links
  • sockets
  • devices

Но так как они считаются "файлами", то можно ls их переименовывать, перемещать и, в зависимости от типа специального файла, посылать данные в них/из них.

13
27.01.2020, 19:40

Модули загружаются при загрузке системы через Initial RAM Disk a.k.a the initrd . В разделе «Обоснование» говорится:

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

Ubuntu, как и многие другие дистрибутивы, выбирает загрузку каждого драйвера устройства в этот initrd, независимо от того, нужен ли драйвер или нет, а также независимо от того, присутствует ли устройство в системе или нет. вся вещь загружается в ОЗУ, а затем при запуске обнаруживаются использованные модули, а неиспользуемые удаляются из ОЗУ. Использование этого подхода гарантирует, что Ubuntu всегда будет запускаться в любой системе независимо от настройки. Ubuntu имитирует монолитное ядро, используя конструкции микроядер. См. Причина, по которой это работает


  1. Модуль rt2800usb всегда загружается при загрузке, поскольку модуль был включен в initramfs , на который ссылался Жиль. Initramfs является преемником initrd, поэтому он всегда будет показан lsmod . Обратите внимание, что недавно скомпилированный модуль можно вставить в ядро с помощью modprobe с последующим именем модуля.

При тестовой перезагрузке системы с отсоединенным беспроводным адаптером. Если все идет хорошо, модуль не будет перечислен в выходных данных lsmod , потому что во время загрузки процесс обнаружения, запущенный initramfs и системой init, не обнаружил устройство во время зондирования, и модуль был удален из ОЗУ.

  1. Для удаления модуля во время работы системы можно использовать такие команды, как rmmod или modprobe -r с последующим именем модуля. При следующей загрузке модуль будет перезагружен. См. Выше. В большинстве случаев модуль не удаляется динамически, так как это приведет к отключению горячей установки, т.е. после удаления модуля устройство, использующее его, не может быть обнаружено снова при замене.

Чтобы удалить модуль из lsmod , необходимо удалить его из образа initramfs, созданного перекомпилированием ядра без выбранного модуля, а затем перестроить образ. При этом блокируется все обнаружение указанного модуля.

-121--28962-

Поэтому /var/www/public _ html на самом деле является папкой Windows, но /var/www/data - нет? Вы пытаетесь создать символическую ссылку из каталога Windows в каталог Ubuntu на виртуальной машине.Нет пути, что Windows может поддерживать такой объект.

Для расширения вышесказанного: я думаю, что суть в том, что хост Windows настроен как файловый сервер, обеспечение доступности C :\Users\Tom _ Hart\Documents\development\public _ html клиентам - в частности, предоставление доступа для чтения/записи к образу Ubuntu, таким образом, Ubuntu может читать, изменять и создавать объекты в этом каталоге Windows и в нем. Но, в общем, серверы не имеют видимости своих клиентов (Каково бы вам было, если бы Google начал индексировать ваши файлы и вернуть их в результатах поиска?) Если образ Docker не экспортирует свои файлы, У Windows нет пути на доступ к /var/www/data - или даже понять такой путь; например,

     C :\Users\Tom _ Hart\Documents > notepad/var/www/data/cache/widget/overlay/ что-то 

не сработает (может показаться, что вы имеете в виду C :\var\www\data\cache\... ). Кажется естественным, что Windows откажется от создания символической ссылки, в каталоге Windows, к ресурсу, к которому не могут получить доступ процессы Windows.

-121--89256-

Каталоги являются файлами, поскольку в системах Linux используется универсальная модель ввода/вывода . В модели все в системе является файлом, и к нему можно получить доступ с помощью одних и тех же системных вызовов и различных команд.

Они имеют особый тип, потому что их i-узлы имеют метку для типа файла и имеют специальную структуру, состоящую в том, чтобы быть таблицей имен файлов и ссылок на другие i-узлы. Эти пары имя-ссылка, также известные как «hardlinks», в i-узле каталога перечисляют файлы «внутри» каталога.

Каталоги предназначены только для организации файлов. Когда файл «перемещается» из каталога в другой, сам файл не перемещается на диск. Просто запись в одном каталоге i-node удаляется и записывается в другой каталог i-node.

2
27.01.2020, 19:40

La respuesta aceptada no es completamente correcta. en los sistemas POSIX, los "inodos" apuntan a archivos y directorios. Los descriptores de archivos solo son exclusivos de un proceso y no de un sistema. Sin embargo, los inodos son únicos, aunque más de un inodo puede apuntar a un solo archivo. Habría comentado sobre la respuesta aceptada, pero no pudo debido a la restricción de representantes.

-3
27.01.2020, 19:40

Теги

Похожие вопросы