Внутренняя структура каталогов зависит от используемой файловой системы. Если Вы хотите знать точно, что происходит, взгляните на реализации файловой системы.
В основном, в большинстве файловых систем, каталог является ассоциативным массивом между именами файлов (ключи) и inodes числа (значения). Что-то вроде этого ¹:
1167010 .
1158721 ..
1167626 subdir
132651 barfile
132650 bazfile
Этот список кодируется в некоторых – более или менее – эффективный путь в цепочке (обычно) блоков 4 КБ. Заметьте, что содержание регулярных файлов хранится так же. В случае каталогов нет никакого смысла в знании, какой размер на самом деле используется в этих блоках. Вот почему размеры каталогов, о которых сообщают du
кратные числа 4 КБ.
Inodes там для связывания блоков, формируя единственный объект, а именно, 'файл' в общем смысле. Они определяются числом, которое является некоторым адресом, и каждый обычно хранится как единственный, специальный блок.
Управление всем этим происходит в привилегированном режиме. Программное обеспечение просто просит создание каталога с названной функцией int mkdir(const char *pathname, mode_t mode);
при продвижении к системному вызову и всему остальное выполняется негласно.
О структуре ссылок:
Жесткая ссылка не является файлом, это - просто новая запись каталога (т.е. имя – inode ассоциация числа) относящийся к существованию ранее inode объект ². Это означает, что к тому же inode можно получить доступ от различных путей. В частности, с тех пор metadatas (полномочия, владение, … меток времени) хранятся в inode, они уникальны и независимы от пути, выбранного для доступа к файлу.
Символьная ссылка является файлом, и это отлично от своей цели. Это означает, что имеет свой собственный inode. Это раньше обрабатывалось точно так же, как регулярный файл: путь назначения был сохранен в блоке данных. Но теперь, по причинам эффективности в недавних файловых системах расширения, пути короче, чем 60 байтов длиной хранятся в самом inode (использующий поля, которые обычно использовались бы для хранения указателей на блоки данных).
—
1. это было получено с помощью ls -ai1 testdir
.
2. чей тип должен отличаться, чем 'каталог' в наше время.
Java не обязательно поддерживает все типы шифрования, поддерживаемые (по-видимому, MIT) kinit
(libkrb5
).
Возможно настроить типы шифрования, используемые libkrb5
в krb5.conf
файл (обычно в /etc
). Например (не обязательно самые безопасные):
# default_tgs_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
# default_tkt_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
# permitted_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
permitted_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
То, какие типы шифрования поддерживаются, будет зависеть от поставщика/версии JRE и его поставщиков систем обеспечения безопасности.
Вот ссылка на документацию для Java 6 (Oracle JRE):