4

Все файлы с одинаковым содержимым на моем компьютере теперь жестко связаны. (Мои данные полностью дублированы. Это следствие того, как я скопировал свои данные со старого компьютера.)

Какие подводные камни мне нужно знать сейчас, когда определенные действия над одним файлом могут незаметно повлиять на ряд других файлов?

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

Перемещение или переименование файла не является проблемой. Я не вижу неожиданных последствий.

Я не думаю, что копирование жестко связанных файлов является проблемой, но я не настолько уверен в каких-либо неожиданных последствиях в этом отношении. Что я видел, так это то, что при создании копии (на тот же диск) файла с жесткой связью с помощью cp копия остается жесткой (т. Е. Номер инода в копии не изменяется). Копирование в другую файловую систему, очевидно, нарушает жесткую ссылку. (Полагаю, одна ловушка забывает об этом, учитывая, что на моем компьютере 3 жестких диска.)

Изменение разрешений влияет на все связанные файлы. Пока что это оказалось полезным. (Я сделал большое количество жестко связанных файлов только для чтения.)

Кажется, ни одна из вышеперечисленных операций не приводит к каким-либо серьезным неожиданным последствиям.

Однако, как указал мне Дэниел Бек в комментарии, редактирование или изменение файла иногда могут быть проблемой. Это зависит от инструмента и, возможно, типа редактирования. (Например, редактирование небольших текстовых файлов с использованием sed, похоже, всегда разрывает ссылку, а использование nano - нет.) Это дает шанс, что редактирование одного файла может повлиять на все жестко связанные файлы (то есть изменить исходный индекс).

Мое предлагаемое решение - сделать все жестко связанные файлы доступными только для чтения (и это уже в большинстве случаев). Если я не могу сделать это для некоторых файлов, я откажусь от этих конкретных файлов. Есть ли проблема с этим подходом только для чтения?

Я предполагаю, что если я зайду, чтобы отредактировать файл и обнаружу, что он доступен только для чтения, я не забуду отсоединить это имя файла, делая его доступным для записи. Таким образом, одна ловушка может быть забыть это правило. В этом случае мне придется положиться на свои резервные копии.

Я прав в приведенных выше утверждениях? И что еще мне нужно знать?

Кстати, я бегу Kubuntu 12.04. Я также использую btrfs. (У меня есть 2 SSD и 1 HDD на ПК. Я также добавлю внешний жесткий диск USB. Я также подключен к сети и подключаю некоторые общие ресурсы NFS. Я не предполагаю, что какие-либо из этих последних битов имеют отношение к вопросу, но я добавляю их на всякий случай.)

Кстати, поскольку у меня есть несколько дисков (с отдельными файловыми системами), чтобы отсоединить любой файл, все, что мне нужно сделать, это скопировать его на другой диск, а затем переместить его обратно. Тем не менее, использование sed также работает (в моем тестировании). Вот мой сценарий:

sed -i 's/\(.\)/\1/' file1

Удивительно, но это даже не связывает файлы нулевого байта. В моем тестировании он также работает с нетекстовыми файлами без каких-либо специальных опций. (Но я понимаю, что опция --binary может понадобиться в Windows, MS-DOS и Cygwin.) Тем не менее, копирование на другой диск и перемещение назад может быть лучшим способом отсоединения. Для моего варианта использования команда unlink самом деле не "unlink", а "удаляет".

2 ответа2

1

Подводный камень - перезапись файлов.

Некоторые приложения пытаются удалить файл и написать новый с исходным именем. В этом случае имена файлов будут отделены. Другие приложения пытаются напрямую открыть файл для записи. В этом случае содержимое других имен также изменяется. Тем не менее, когда вы делаете все дубликаты связанных файлов R / O, это можно легко распознать.

1

Вот подводные камни, о которых я думал до сих пор:

1. Возможно непреднамеренное изменение содержимого одного или нескольких файлов x при редактировании файла y.

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

ВАЖНОЕ ОБНОВЛЕНИЕ: Вот настоящая ловушка. Иногда редакторы автоматически перезаписывают файл, даже если он доступен только для чтения. Например, у меня был пустой файл с разрешениями 400 и принадлежащий пользователю root. Я открыл файл в nano, отредактировал его и сохранил. Nano не жаловался, что это только для чтения. Все жестко связанные имена файлов теперь имеют неправильное содержание. Так что, к сожалению, создание файлов только для чтения - это не обходной путь, который я ожидал, и это действительно серьезная ошибка.

2. Возможно непреднамеренное создание новой копии файла. Это, по сути, противоположность первой ловушки. Содержимое одного файла может иметь N имен файлов. Редактирование одного из этих имен файлов теперь может привести к двум отдельным элементам содержимого, причем N (количество имен файлов) не изменяется вообще. Я мог не знать о том, что это произошло (если я не обращаю внимание на жесткие ссылки).

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

Тот же обходной путь - единственный, который я придумал - сделать файлы доступными только для чтения, поэтому мне напомнили о необходимости редактирования, чтобы я обращал внимание на жесткие ссылки. (Есть ли лучший обходной путь, например, какой-нибудь способ быстро связать все имена файлов?)

Еще одно (положительное) следствие того, что моя коллекция фотографий была жестко связана с тем, что я могу гораздо быстрее организовать ее сейчас. Например, с помощью этой команды я могу найти все дубликаты фотографий:

find 2>/dev/null /home/me/Pictures -type f -links +1 -printf "%n\t%i\t%d\t%s\t%t\t%p\n" | sort -gr > /home/me/Pictures/duplicatesList.txt

Используя этот список, я могу уверенно удалять имена файлов, которые не хочу сохранять. В конце концов, у меня может не быть больше фотографий с жесткими ссылками.

3. Я не могу думать о третьей ловушке. Если у кого-то больше 2 ловушек, пожалуйста, ответьте, и я приму ваш ответ (при условии, что он лучше моего).

В целом, я не думаю, что жесткие ссылки усложнят мои ежедневные вычислительные задачи, если я сделаю все жестко связанные файлы доступными только для чтения. Я могу сделать это легко с помощью команды, подобной этой:

find . -type f -links +1 -perm /g+w,o+w -iname *.gif -exec chmod 444 '{}' \;

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

Со временем я избавлюсь от ненужных имен файлов и упросту свои данные (и мою жизнь). Если файлы действительно доступны только для чтения и дубликаты гарантированы, я оставлю жесткие ссылки на эти файлы на неопределенный срок.

Однако в некоторых случаях я отменяю связь между файлами и специально оставляю независимые дубликаты файлов. Этот последний случай очень часто встречается в деревьях исходного кода; одно и то же содержимое файла оправдано в нескольких местах и должно быть доступно для записи. Когда я сталкиваюсь с файлом исходного кода, который доступен только для чтения, и мне нужно отредактировать его, я откажусь от ссылки. Как правило, простое редактирование файла приведет к его удалению. Но я могу быть уверен, используя эту команду, которая, как я знаю, отменяет связь с файлами:

sed -i 's/\(.\)/\1/' file1

Примеры:

Вот пример ловушки № 1 выше. Это реальный пример из моей файловой системы, с которым я только что столкнулся.

Я собирался деструктивно редактировать «Копию index.html», потому что я видел файл «index.original.html» и думал, что могу безопасно редактировать копию. Однако оказывается, что файлы были жестко связаны, поэтому редактирование "копии" также изменило бы оригинал.

Вот информация, показывающая, что файлы были жестко связаны:

2   45214   6   6641    Thu Oct 30 10:46:00.0000000000 2008 /Site/FusionAppsVPS/index.original.html
2   45214   6   6641    Thu Oct 30 10:46:00.0000000000 2008 /Site/FusionAppsVPS/Copy of index.html

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .