Жёсткие связи в NTFS
Думаю, многие из вас знают, что в NTFS поддерживаются жёсткие связи, т. е. когда на один и тот же физический файл (в смысле, кучу байтов) указывают несколько имён в дереве папок. Я знаю про это чёрт знает сколько времени, потому, что когда NTFS только появился, я где-то прочитал чем же он так интересен. Однако, с тех времён все эти его модные фишки типа жёстких связей, точек повторной обработки и прочего почему-то отложились у меня как что-то, что чисто гипотетически есть, но реально не работает. Правда же состоит в том, что просто для этого нет интерфейса.
Зачем мне нужны жёсткие связи?
У меня на диске лежит огромная куча музыки, и часто так бывает, что один и тот же трэк встречается в нескольких местах, например, на альбоме и на каком-нибудь сборнике. Раньше я делал так: оставлял трэк только на альбоме, а в папке со сборником ставил на него ярлык. Жалко же тратить место на диске на два одинаковых файла. Но это не очень удобно. Если такой сборник записать кому-нибудь, то у него этот ярлык уже будет вести в никуда. Да и вообще, как-то некрасиво.
И что-то решил я снова изучить тему жёстких связей, потому, что это как раз тот случай, где они нужны. Быстро выяснилось, что:
fsutil hardlink create <где> <из чего>При выполнении этой команды создаётся новое имя для того же файла (который «из чего»). Теперь у вас есть два файла по 10 мегабайт, которые в сумме занимают 10 мегабайт. Приятно. Особенно когда таких файлов сотни. Все эти файлы (точнее, имена, — файл-то один) абсолютно равноправны. Их можно независимо переименовывать или таскать по диску туда-сюда. Просто контент у них остаётся один и тот же. Удаление любого из них никак не отразится на жизни второго. Контент удалится только тогда, когда на него не будет указывать ни одного такого имени.
Всё это здорово, но командную строку я не люблю. Хоть это и очень по-хакерски — сидеть в командной строке, — но я предпочитаю как-нибудь чтобы побыстрее, а не покруче. Ну и, в общем, нашёл я бесплатную программку Alax.Info NTFS Links. Она добавляет в Проводник поддержку жёстких связей (и ещё некоторые фишки NTFS, которые мне малоинтересны). После установки программы единственное, что я заметил — это появление пункта Create Hard Link в меню, которое появляется после drag’n’drop’а правой кнопкой. Видимо, остальные обещанные штуки появятся после перезагрузки, которой мне заниматься пока что лень. К остальным обещанным штукам относится появление по правой кнопке в папках пункта Paste as Hard Link, а также добавление во всплывающей подсказке к файлу указания числа жёстких связей.
Скачать программку можно где-то тут (322 КБ). Скачать новый трэк Theoreme — Sachi можно не знаю где, но я вам очень советую это сделать, так как трэк просто обалденный (как я плавно перевёл тему, а?)
Теперь мне интересно другое: как узнать, сколько места на диске действительно занимает папка Music? В окне «Свойства папки» размер считается как сумма размеров всех файлов, и, поскольку проводник ничего не знает о жёстких связях, каждый файл считается столько раз, сколько этих жёстких связей у него есть. Кто знает?
Ссылки — это жутко удобная вещь, тут спорить не могу. Единственное гениальнейшее примененение (не знаю, были это происки MS или наши постарались...) видел достаточно давно диск с Windows 2000 Server в 3 (!) вариантах на одном CD. В сумме все это добро занимало больше гигабайта, помещалось в распакованном виде на CD, сделано было естественно, на ссылках. Знал я о них давно (и про NTFS-ные, а уж про Unix’овые — тем более), так что удивился не сильно, но запомнил хорошо.
Про коммандную строку — это ты зря. Только командная строка должна быть нормальная. Например, нахожусь я в дебрях аудио-дерева, в третьем диске, во втором варианте альбома такого-то автора, год такой-то. Вложенность охрененная. Хочу перейти в альбом такой же вложенности другого автора. Это пять уровней вверх, потом — вниз. Если исполнителей много — даже мышкой прокручивать долго. (Да, я знаю, сам могу быстро, но...). В нормальной командной строке пишем что-то вроде
cd /Mu[tab]/Au[tab]/2006/Na[tab]/A[tab]/3[tab]
(дальше можно извратиться, и, например, запустить командный же плеер. Ну, изврат)
mpg[tab] ./*
эээ, все. :) Мгновенно (что там грузить-то, плеер-то командный) начинается воспроизведение.
Так что нормальная командная строка — это хорошо... Другое дело, что для винды это почти никак не получить, поэтому приходится искать другие нормальные проги. Ну, такие, как эта. :)
Весь этот же mutab-autab можно делать в том же проводнике, и при этом ты намного нагляднее видишь что делаешь. Извратиться всегда можно, вопрос в том, нужно ли. (Нет.)
Кстати, в никсах есть две ссылки: жесткие и мяг... символические :)
Тут тоже есть чё-то такое, но я не понял как это работает, а главное — зачем это нужно мне :-)
на ntfs есть ещё такая дивная вещь, как ссылки на папки… ;)
когда одна папка лежит в 2-5 местах.
а по управлению ссылками — Far — он это умеет.
Ну вот сделал я теперь ссылку на папку, а удалять боюсь. Вдруг проводник удалит и оригинальную папку тоже? Ыыы...
Удалит, они про это пишут везде. Поэтому я это и не трогаю: не до конца пока понимаю физику происходящего.
А Total Commander удалил без проблем. Уфф. :)
Жесткие и «мягкие» (символические) отличаются именно тем, что жесткие связаны с самим файлом, удаляется жесткая — удаляется файл. Символичееская — это просто ссылка, её можно удалять без проблем, ничего не будет. Поэтому в *nix, например, чаще используются символические ссылки.
Плюс, там наверняка (домыслы, точно не помню) по-разному с правами работают при разных типах ссылок.
На самом деле всё ровно наоборот: удаляется жёсткая связь — файл остаётся. Он удалится только тогда, когда с ним не будет ни одной жёсткой связи. А вот если попытаться удалить папку «символическую», то уничтожится содержимое настоящей, потому, что проводник будет рекурсивно обходить её содержимое. Поэтому символические нужно не удалять, а «разрывать», а для этого стандартного средства нет. То есть для конечного пользователя символические ссылки опасны, можно случайно убить то, что не хотел, а вот с жёсткими связями такой проблемы нет.
Прикольно, но тест в фаре показал, что те ссылки, которые он создает — при удалении удаляется не все, но только то, что удаляешь. То есть:
Пробовал и удалять оригинальный файл — дурацкая ссылка тоже осталась.
Так что в ntfs, похоже, жесткие ссылки не такие жесткие :)
Чувак, ровно в этом смысл жёстких связей.
Жёсткость состоит в том, что нельзя случайно удалить одно, удаляя другое. Ты не создаёшь ссылку на файл. Ты создаёшь несколько имён одному и тому же файлу. Они все равноправны. Когда ты удаляешь одно из имён, сам файл удаляться и не должен. И только когда ни одного имени не останется, удалится содержимое файла.
не понял… ;-)
Есть:
кучка байтов.
1 ссылка на кучку байтов.
2 ссылка на кучку байтов.
Удаляем 1 ссылку — остаётся вторая.
Удаляем вторую — ссылок больше не устаётся, кучка байтов удаляется.
А с папками — я удаляю через фар, он мне при удалении говорит, мол „символическая ссылка, что с ней сделать? (разорвать/удалить)”
Ну, всё логично вроде бы. А что не понял?..
Hard links на NTFS разделах будут доступны для файлов, через drag and drop и через copy/paste as hard link но только в пределах одного раздела (C:, D:, ...)
Soft links (junctions, reparse points, symbolic links) будут доступны для папок на NTFS разделах. Причем такая ссылка может вести и на другой раздел, необязательно NTFS.
Предполагается, что это будет работать так. Если какая-то команда «не появилась» в меню, то скорее всего не выполняется какое-то из условий (например, hard links только в пределах одного раздела).
Не понял, «будут» — это где и когда? Почему в будущем времени?..
«Будет» в смысле что уже должно так работать. Но, как всегда есть некоторые особенности.
К примеру, если скопировать в explorer’е файл, а потом right-click’нуть на свободном месте (так чтобы не было отмеченных файлов), в это контекстное меню explorer по неизвестной причине не хочет вносить дополнительные команды, хотя Paste там есть. Если right-click’нуть на конкретной директории, то команды доступны.
Какая-то программка аналогичная вашей это всё же делает, судя по скриншотам, но я её не качал, что-то мне не понравилось в ней.
А слабо сделать, чтобы при обычном Ctrl+C/Ctrl+V это работало? То есть, если я делаю Ctrl+V на том же томе, откуда подцепил файлик, то, например, спрашивает «Копировать или сделать жёсткую связь?» Вроде было бы круто.
Ещё было бы круто, если оно по-русски добавляло пункты в меню, раз уж вы, оказывается, русскоговорящий товарищ :-) Не то, чтобы меня смущало английское, просто Create Hard Link среди «Копировать» и «Переместить» как-то неопрятно смотрится.
Спасибо за замечания. По мере наличия времени и желания будем совершенствовать.
Это вам спасибо!
Я говорил интерпретацию ссылок в юниксе. То, как это делается в Linux в частности. Я регулярно делаю символические ссылки, потом их удаляю, потом снова делаю.
То, что в NTFS — все наоборот, ну, судьба такая. Зачем это — черт их знает.
Мы тут про NTFS, ваще-то :-)
Зачем это — я написал в заметке вполне чётко. Зачем связи, от которых возникает риск удалить то, что ты удалить не хотел, — вот это мне не понятно.
http://www.cyberciti.biz/nixcraft/vivek/blogger/2006/01/understanding-unixlinux-symbolic-soft.php
Жесткие — это в разных директориях запись на один файл.
Символическая — это отдельный специальный файл, в котором указано, что это ссылка.
Это никсовый вариант. Ну, вот еще:
http://en.wikipedia.org/wiki/Symbolic_link
http://en.wikipedia.org/wiki/Hard_link
Ну, дак где противоречие-то? Тут ровно то же самое. Тогда зачем ты утверждаешь, что в линуксе наоборот?
Кстати, в свойствах папки есть два разных размера — «Size» и «Size on disk». Вот второй, по идее, должна всё правильно показывать.
Я тоже на это надеялся. Нет.
По моему, достаточно представить, как выглядит структура NTFS, чтобы понять, что такое жетские ссылки.
NTFS разбит на две зоны — MFT (12% от объема, если мне память не изменяет — метафайл) и зона самих файлов. Это как две таблицы в СУБД, хранящие древовидную структуру, где первая хранит зависимости между сущностями (файлами, каталогами — в NTFS не суть), а вторая — сам контент сущностей.
%%_____________________________
MFT | FILES |
12% | |
——————————————————————————%%
(на самом деле структура NTFS сложнее: вторая зона разбита на две части, в начале второй части дубрируется метафайл — но это в данном случае знать не обязательно)
Когда мы создаем файл, происходят следующие вещи: во зону файлов записывается только содержимое файла, а в метазону — ссылка с указанием того, где это содержимое расположено.
Когда мы создаем hard link, мы просто добавляем в MFT-зону ещё одну ссылку на уже существующее содержимое во зоне файлов. Ссылки эти идентичные, и фактически ни чем друг от друга не отличаются. Поэтому и разницы нету, какую из них удалять — само -то содержимое останется (и будет там лежать, пока число ссылок на него не станет равно нулю, как ты, Илья, и подметил).
Я говорил, что наоборот, потому что склероз. Мне это было не нужно, и я не помнил, что и как. Кстати, в википедии написано, что в NTFS полноценные символические ссылки появятся только в Висте...
Какой смысл в «полноценных символических ссылках», учитывая, что:
Символические ссылки полезны, они могут пересекать границы разделов.
Ярлыки Windows — это и есть недосимволические ссылки. Так что твоя фраза звучит странно «какой смысл в символических ссылках, если есть символические ссылки»... Когда работа с ярлыками будет возложена на NTFS, а не на Windows — это будут нормальные символические ссылки, которые полезны.
Моя фраза мне не кажется странной.
Действительно, зачем нужны символические ссылки, если уже есть символические ссылки?
Что тебе кажется странным в этой фразе? Мне лично странным кажется твоё желанием поиметь то, что уже есть.
Ответственность за разыменование ярлыков лежит на приложении. То есть, если у меня в ftproot лежит ярлык на каталог, а ftp-сервер не умеет разыменовывать ярлыки, то юзер скачает именно ярлык как файл. А если рядом лежит симлинк на тот же самый каталог, то разыменованием занимается драйвер файловой системы. И юзера пустят погулять по каталогу и что-нибудь из него скачать, независимо от того, чего там запрограммировано в сервере.
Что касается удаления Explorer’ом ссылок и всего, что под ними — так это надо права доступа грамотно расставлять. Я себе завёл три правила: (1) всё, на что ведут символические ссылки, принадлежит Administrator’у и только он может это удалять и перезаписывать; (2) не работать под Administrator’ом без крайней на то необходимости; и (3) не работать в Explorer’е без крайней на то необходимости.
А что до настоящего размера каталога — то это вообще тема неопределённая. Размер каталога зависит от того, для чего он нам нужен. Если мы хотим его скопировать на FAT32-раздел, нас интересует суммарный размер всех файлов. Если мы хотим узнать, сколько освободится места, если мы сейчас это всё удалим — нам нужен размер уникальных файлов внутри, за исключением тех, на которые есть ссылки снаружи, и содержимого симлинков. Если мы хотим его скопировать на NTFS-раздел с сохранением структуры хард- и симлинков, нам нужен суммарный размер всех уникальных файлов внутри, включая симлинки. А так как узнать, откуда ещё есть хардлинки на конкретный файл, практически невозможно (кроме как перебрав все каталоги на разделе), то и задача невыполнима.
По поводу сравнения симлинков и ярлыков — вроде бы понял, спасибо.
Про правила — отличные правила! Ещё проще завести одно: не включать компьютер никогда. А если я люблю пользоваться Проводником из-под Администратора, мне что, повеситься?
Ну и насчёт вот этого:
!!А что до настоящего размера каталога — то это вообще тема неопределённая.!!
Настоящий размер каталога — тема вполне определённая. Это количество байт, которые он занимает на диске. Не то, сколько он будет занимать, если его то или сё, а сколько занимает фактически, сейчас. То есть, сумма всех файлов (каждый реальный файл считается по 1 разу, а не по столько, сколько у него хардлинков) плюс суммы всех записей в MFT.
Все эти «если» тоже могут быть интересны, но это не называется размером каталога.
Другое дело, что технически может быть не так и просто это посчитать. Но физический смысл эта величина имеет вполне конкретный.
На счёт того, откуда ещё есть хардлинки... Я так полагаю, раз у NTFS есть API, чтобы узнать, сколько всего хардлинков есть у файла, то должны быть способы и узнать, откуда эти хардлинки ведут.
А Если на этот файл есть Три хардлинка, и Два из них лежат в Этом каталоге, а Третий — в каком-то совершенно Другом? Тогда мы считаем этот файл лежащим тут, или не считаем? А в том Другом каталоге мы его считаем лежащим или не считаем?
!!Я так полагаю, раз у NTFS есть API, чтобы узнать, сколько всего хардлинков есть у файла, то должны быть способы и узнать, откуда эти хардлинки ведут.!!
Функция CreateHardLink создаёт новый хардлинк на имеющийся файл. Функция GetFileInformationByHandle возвращает количество хардлинков вместе с датами создания/изменения/последнего доступа, размером и атрибутами. Кроме того, она возвращает уникальный идентификатор файла на компьютере. Других API для работы с хардлинками нет. Поэтому, чтобы получить список всех хардлинков на наш файл, нужно взять его ID и выполнить по всему диску полный поиск всех файлов, спросить у каждого ID и сравнить. А если часть хардлинков лежат в каталогах, где у нас нет прав доступа? Тогда мы их не найдём.
Когда мы тыкаем на сам файл в «Свойства», мы считаем там его размер или не считаем? Считаем. И пофигу, что где-то ещё есть хардлинки, логично? То же самое ровно и с директориями: в этой директории файл лежит — значит считаем. И плевать, что лежит где-то ещё. Зачем делать вид, что что-то непонятно?
На счёт API — я не в теме. Неужели у NTFS нет API для нахождения файла по ID? Если действительно нет — ну что ж, значит не повезло.
2Centaur
Внимательнее читайте комментарии. Hardlink может существовать только в том разделе, в котором лежит сам файл. Поэтому и высчитывание объема никаких нареканий вызывать не должно.
2Илья Бирман: я, между прочим, я не меньший извращенец, чем ты, и тоже пользуюсь Explorer-ом... Однако на днях нашёл достойную альтернативу — Directory Opus. Он ни чем не отличается от «Проводника», однако очень быстр, и не жрет ресурсы.