Сбрасываются права доступа при удалении жесткой ссылки NTFS

Если вы работаете с жесткими ссылками (hard links) на NTFS, возможно, замечали странное поведение: при удалении одной из ссылок права доступа оставшегося файла внезапно сбрасываются. Это не баг, а особенность файловой системы, связанная с тем, как Windows обрабатывает метаданные. Давайте разберемся, почему так происходит и какие есть обходные пути.

Почему удаление жесткой ссылки ломает права доступа

Жесткие ссылки – это не отдельные файлы, а разные «имена» одного физического объекта на диске. Когда вы создаете их через mklink /H, обе ссылки наследуют разрешения родительской папки (если включено наследование). Но при удалении одной из ссылок через проводник или стандартный Delete происходит следующее:

Файл отправляется в корзину, а корзина автоматически сбрасывает унаследованные права (ACL).
Оставшаяся ссылка теряет связь с исходными разрешениями папки, так как обновленный ACL из корзины становится ее новым набором прав.

Кстати, это касается только удаления через интерфейс с корзиной. Если файл удаляется навсегда (например, через Shift+Delete), ACL не меняется, но появляется другая проблема – «призрачные» разрешения (о них позже).

Проверьте сами: создайте папку с наследованием, добавьте файл и жесткую ссылку. Удалите одну из них – оставшийся объект получит уникальные права вместо унаследованных.

Как сохранить разрешения: рабочие методы

Есть два основных подхода, в зависимости от ваших задач.

1. Используйте символические ссылки вместо жестких

Символические ссылки (symlinks) не связаны с ACL исходного файла. Они работают как перенаправление и не влияют на разрешения при удалении. Создаются через mklink без флага /H:

mklink C:db C:da

Минус: они не поддерживаются некоторыми старыми программами (например, резервными инструментами).

2. Удаляйте файлы, минуя корзину

Если жесткие ссылки критичны, избегайте отправки в корзину:

Нажмите Shift+Delete в проводнике.
Используйте командную строку: del /f /q путь_к_файлу.

Но будьте осторожны: при таком удалении ACL не обновляется. Если до этого права были изменены вручную, оставшаяся ссылка сохранит «старую» версию, даже если папка-родитель обновилась. Это и есть те самые «призрачные» разрешения.

3. Восстанавливайте наследование вручную

Если проблема уже возникла:

Кликните правой кнопкой на файле → Свойства → Безопасность.
Выберите Дополнительно → Отключить наследование → Преобразовать унаследованные разрешения… (это странный пункт, но он сработает).
Удалите все ненужные записи и включите наследование заново.

Важно: не удаляйте жесткие ссылки между папками с разными правами. Например, если исходный файл в C:Secret, а ссылка – в C:Public, их ACL могут конфликтовать при любом удалении.

Подводные камни и нюансы

Жесткие ссылки – мощный инструмент, но их лучше использовать в «статичных» сценариях. Например, для резервных копий в пределах одной папки с одинаковыми правами. Если же вы активно меняете ACL или работаете с разными директориями, символьные ссылки или junction points (для папок) надежнее.

Кстати, если вы всё же столкнулись с «призрачными» правами, поможет утилита AccessChk от Sysinternals. Она покажет текущие ACL и позволит массово исправить их через командную строку.

И помните: при удалении через корзину система фактически создает новую версию метаданных файла. Это особенность NTFS, а не ошибка в вашей настройке. Просто выбирайте подходящий метод удаления – и всё будет в порядке.