Как развязать (удалить) специальную жесткую ссылку ".", созданную для папки?

Попробуйте следующее:

Из списка встроенных встроенных функций в ksh:

$ ksh -c 'builtin' 

Это единственные встроенные функции, полезные для ответа на ваш вопрос:

echo kill print printf read

Итак, похоже, что единственный способ «прочитать файл» - это использовать read.
Давайте определим пару функций (скопируйте и вставьте в CLI):

function Usage {
    echo "fileread: filename [from line] [to line]"
    exit 1
}

function fileread {
    [ "$#" -lt 1 ] && echo "please supply the name of a file" && Usage
    linestart=${2:-1}
    lineend=${3:-0}
    i=0
    while IFS=$'\n' read line; do
        i=$((i+1))
        [[ "$i" -lt "$linestart" ]] && continue
        [[ "$lineend" != 0 && "$i" -gt "$lineend" ]] && continue
        echo "$i $line"
    done <"$1"
}

А затем вызовите функцию (в качестве примера):

$ cd /var/run
$ fileread sshd.pid 10 20
29
19.10.2016, 09:50
4 ответа

Удалить технически возможно. , по крайней мере, в файловых системах EXT4. Если вы создаете образ файловой системы в test.img , смонтируйте его и создайте папку test , а затем снова отключите ее, вы можете отредактировать ее с помощью debugfs :

debugfs -w test.img
cd test
unlink .

debugfs не жалуется и покорно удаляет . запись каталога в файловой системе. Каталог test все еще можно использовать, с одним сюрпризом:

sudo mount test.img /mnt/temp
cd /mnt/temp/test
ls

показывает только

..

, так что . действительно пропал. Еще cd. , лс. , pwd по-прежнему работают как обычно!

Я ранее проводил этот тест с помощью rmdir. , но при этом удаляется индексный дескриптор каталога ( огромный благодаря BowlOfRed за , указывающий на это ), в результате чего test болтается запись в каталоге и является реальной причиной возникших проблем. В этом случае папка test становится непригодной для использования; после монтирования образа запуск ls создает

ls: cannot access '/mnt/test': Structure needs cleaning

, а в журнале ядра отображается

EXT4-fs error (device loop2): ext4_lookup:1606: inode #2: comm ls: deleted inode referenced: 38913

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

Все это показывает, что . существует как особый объект в файловой системе EXT4. У меня сложилось впечатление от кода файловой системы в ядре, которого оно ожидает . и .. и предупреждает, если они не существуют (см. namei.c ), но с отключением . Тест на основе Я не видел этого предупреждения. e2fsck не любит отсутствующий . запись каталога и предлагает исправить ее:

$ /sbin/e2fsck -f test.img
e2fsck 1.43.3 (04-Sep-2016)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Missing '.' in directory inode 30721.
Fix<y>?

Это воссоздает . запись в каталоге.

46
27.01.2020, 19:38

Невозможно удалить эту запись каталога. . Запись означает «этот каталог», запись .. означает «родительский каталог этого каталога». На самом деле это не жесткие ссылки, это просто способ создания / представления структуры каталогов.

5
27.01.2020, 19:38

Как говорится в ответе «возможный дубликат» сообщения , стандарт POSIX указывает, что если rmdir попытается удалить текущий каталог , он выйдет из строя.

Все, что вы строите, должно иметь фундамент. Трудно определить относительные пути без возможности сказать «здесь». Так что '.' определяется как «здесь».

Кроме того, вы можете удалить точки и точки. Напишите свою собственную ОС, которая их не определяет. Хотя Unix (и, соответственно, Mac OSX), Linux и даже MS DOS и Windows используют точку и точку.

TL; DR - «точка» в определении ОС.

0
27.01.2020, 19:38

Как описано в Заметки Lion по исходному коду Unix 6 ранние версии Unix имели файл на диске, где и файлы, и каталоги были представлены на диске структурами inode. Был специальный бит, который указывал, что содержимое файла было каталогом. Каждый индексный дескриптор имел ссылку на собственный индексный дескриптор, который позволял файлу знать, в каком каталоге он находится. Исключением был каталог '/', который принадлежал самому себе. Также была ссылка на содержание. Если inode не имел содержимого, его можно было вернуть в свободный список. Поскольку каталог был просто благословенным файлом, даже пустой каталог должен иметь содержимое, чтобы не допустить его сборку мусора. Таким образом, .. был ссылкой inode на родительский inode и. был там, чтобы указать, что каталог все еще можно использовать. rmdir (вызвав unlink) может удалить. каталог, если бы не было другого содержимого, а затем индексный дескриптор переместился бы в список свободных, когда на него больше не было ссылок.

2
27.01.2020, 19:38

Теги

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