» NTFS, hard links (жёсткие ссылки): проблема.

После экспериментов с хардлинками на NTFS обнаружился файл, у которого прописано, что есть 2 жёсткие ссылки. Реально же на диске больше ни одной ссылки на эту же файловую запись не обнаруживается: делал поиск по всем файлам на разделе, поскольку в NTFS они не могут быть на разных разделах. Поиск делал очень просто, в лоб: прочёсывается весь диск и проверяется, сколько у каждого файла жёстких ссылок. У того, "второго" файла их тоже должно быть две, вот и выводятся все файлы, число ссылок которых равно 2. Так вот, к моему "странному" файлу просто нет пары! Из всех выведенных на экран файлов нет ни одного файла с таким же размером, не говоря уж про содержимое. Ошибки при поиске можно исключить, т.к. пользовался Тоталом. chsdsk молчит, как партизан: всё чисто, всё отлично. Подозреваю, что проблема возникла из-за использования Notron Undelete, но всё равно не понимаю, как такое могло произойти и как это исправить.

Конечно, можно этот файл просто удалить, но не уверен, что это решит проблему. Скорее всего, на диске останется этот файл, просто на него не будет ни одной файловой записи. Проблема не столько практическая, сколько теоретическая: просто интересно, в чём тут дело, и как такая ситуация получилась?

CaptainFlint
Мне кажется вопрос для форума ОСки. Вряд ли это железный вопрос.

Dr StandBy
Да я вот и сам не знаю... Вопрос касается, собственно говоря, файловой системы: её структуры, возможностей, багов и т.д. Это не ОС, не Программы, не хардвара... Нет полностью соответствующего раздела, но поскольку про NTFS спрашивают всё-таки здесь (и ещё на Общем хардварном), то я решил запостить сюда.

CaptainFlint

Цитата:

У того, "второго" файла их тоже должно быть две

Из справки

Цитата:

Жесткая связь представляет запись каталога для файла.

Т.е. создается множество имен для одного файла. Другими словами, файл физически, на диске одЫн, потому того "второго", у которого "должно быть" две ссылки, ты и не находишь.
Тема действительно для ОС, потому как обсуждается работа файловой системы, единицы логической и входящая (в данном, конкретном случае) в понятие ОС, в отличии от единиц физических, обсуждаемых в разделе Железо. Пусть мужики ее в ОСки перекинут.

Цитата:

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

Не совсем так.
Рассмотрим "нормальную" ситуацию, т.е. как должно быть при нормальной корректной работе файловой системы.
Пусть у нас на диске есть некоторое занятое пространство размером, скажем, 1 мегабайт. И это пространство считается файлом. Далее: в счётчике ссылок прописано 2. Это значит, что на всём разделе существуют две файловые записи, которые ссылаются на этот блок данных. А это в свою очередь означает, что поиск по всему разделу обязан обе эти файловые записи найти. Они могут быть в разных подкаталогах, на разных уровнях вложенности, иметь разное имя, но они обязаны обе существовать (иначе бы счётчик не был равен двум!). И когда я у этих двух файловых записей попытаюсь узнать счётчик жёстких ссылок, для них обеих выдастся число 2.

Вот как я себе представляю нормальную ситуацию. А теперь то, что у меня в реальности: есть некая файловая запись, ссылающаяся на файл, счётчик ссылок которого равен двум. Это означает, что где-то на разделе существует ещё одна файловая запись, ссылающаяся на этот же блок данных. И если я у той, второй файловой записи запрошу количество жёстких ссылок у файла, на который она ссылается, я, естественно, должен получить 2. Однако этой самой второй записи на диске нету! Ни в одном подкаталоге, нигде. Поскольку это входит в противоречие с тем, что я описал выше, я и запостил этот вопрос. Конечно, я могу неверно представлять себе принцип работы жёстких ссылок, но тогда просьба объяснить, в чём именно я ошибся.

Насчёт переброски темы сообщил модераторам.

CaptainFlint

Цитата:

просьба объяснить, в чём именно я ошибся

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

Цитата:

Далее: в счётчике ссылок прописано 2.

Что есть счетчик ссылок? Кто\что этот счетчик тебе показывет, подробно... название, ссылку где лежит и т. п.

Цитата:

Это значит, что на всём разделе существуют две файловые записи, которые ссылаются на этот блок данных.

Еще раз, если файл физически один, то в MFT, файловых записей никак не может быть две. Или, тогда поясни, что ты вкладываешь в понятие "файловая запись"? Для меня, это запись о файле в таблице файлов. Одна запись-один файл. На один файл может быть больше одной записи, если
а) он сильно фрагментирован
в) у него много атрибутов
и тогда, первая запись называется базовой, она хранит адреса других записей, но, в общем, они все относятся к одному файлу, потому, в нашем случае, речь идет именно об одной файловой записи.
Другое дело, если ты совместил понятие "файловая запись" с понятием "атрибут", которые могут встречаться в "файловой записи" дважды, как и в нашем случае, т.е. файл имеет несколько имен (жесткую ссылку), стало-быть два атрибута $FILE_NAME. Другой пример наличия двух атрибутов в "файловой записи" - это сгенерированное краткое имя MS-DOS для файла с длинным именем. Но, через поиск в лоб в файле менеджере, врядли ты увидишь все атрибуты файла, хотя... возможно и существуют некие плагины Total Commander'a для просмотра атрибутов файла, не ведаю...
Ошибка твоя, по-видимому, в этом. Ты ищешь вторую файловую запись, а ее быть не может, потому как файл одЫн.

По-видимому, у нас некоторое разногласие в терминах. Попробую систематизировать. Заранее извиняюсь за длинный пост.

Прежде всего хочу уточнить, что я сейчас буду рассматривать работу исключительно с точки зрения обычного пользователя, который знать не знает про всякие MFT, файловые потоки и т.д. Для него то, что мы называем файловыми записями (или ссылками) - это просто файлы, и всё. В угловых скобочках я буду писать уточнения, "невидимые" для этого обычного пользователя, и там я буду использовать максмально корректную терминологию, обозначенную в первой же такой вставке.
Итого:
1. На диске (под диском здесь и далее я понимаю исключительно NTFS-раздел) существуют файлы и каталоги в стандартной древовидной организации. <Под файлами тут подразумеваются именно файловые записи внутри каталогов! Есть три "уровня": 1 - собственно данные файла, лежащие где-то на диске; 2 - MFT-запись, указывающая, где эти данные собственно лежат; 3 - одна или несколько файловых записей внутри различных каталогов, ссылающиеся на эту самую MFT-запись. Пользователь видит только самый верхний уровень, т.е. файловые записи в каталогах, и, естественно, воспринимает их как самые обычные файлы. Здесь и далее под файловыми записями я понимаю исключительно записи внутри каталогов. Для записей внутри MFT я так и буду писать: MFT-запись.> Для каждого из файлов можно определёнными методами узнать некую, пока что абстрактную, величину: счётчик жёстких ссылок (я пользовался двумя вещами: плагином собтственного изготовления и расширением оболочки Windows, которое добавляет в диалог свойств файла новую вкладку с информацией о количестве ссылок и о потоках, оба способа дают один результат, что неудивительно).
2. Теперь что происходит, когда пользователь создаёт жёсткую ссылку. Пусть "оригинальный" файл - C:\123\file.dat, а тот, который создали - C:\456\file2.dat. Пользователь, создав этот второй файл, запрашивает количество ссылок у первого файла, и узнаёт, что теперь это число равно двум, тогда как раньше оно равнялось 1. <Оно и логично: ведь раньше на соответствующую MFT-запись ссылалась только одна файловая запись, а теперь - две.> Итого, пользователь теперь видит ДВА файла, у обоих одинаковое содержимое, одинаковый размер, атрибуты и т.д. <Под атрибутами я понимаю самый что ни на есть стандартный набор: Скрытый, Системный, Только для чтения...> При попытке изменить один файл, меняется и другой. Если пользователь попытается узнать число ссылок у ВТОРОГО файла, он получит то же самое значение - 2. <Опять-таки, логично. Вторая файловая запись ведь ссылается на ту же самую MFT-запись, у которой сейчас счётчик установлен в значение 2.> Теперь если пользователь проведёт поиск всех файлов на диске, у которых счётчик ссылок равен двум, то он найдёт ДВА файла: C:\123\file.dat и C:\456\file2.dat.
3. При удалении любого из этих двух файлов пользователь заметит, что свободное место на диске не увеличилось (так же, как при создании ссылки оно не уменьшалось), а счётчик другого (оставшегося) файла станет равным снова 1. <Правильно: файловая запись была удалена, счётчик ссылок MFT-записи, на которую ссылалась эта файловая запись, при этом уменьшился, но поскольку он нуля не достиг, данные файла удаляться не стали.> Теперь у него снова один-единственный файл.

Так вот, как несложно понять, этим пользователем являюсь я сам. Я ожидаю, что ситуация будет в точности такая, как я только что длинно и пространно описывал. Но, к моему удивлению, ситуация, наблюдаемая на моём диске, отличается от вышеописанной. Я вижу ОДИН файл <файловую запись>, у которого счётчик ссылок равен ДВУМ, и поиск по всему диску не находит больше ни одного файла <т.е. - ни одной файловой записи, не считая первой!>, у которого счётчик тоже был бы равен двум!

Основная моя предпосылка: если счётчик равен двум, то значит, на диске просто обязаны находиться две различные файловые записи, ссылающиеся на одну MFT-запись. Эти файловые записи будут мне видны как самые обычные файлы. Но поиск, который, понятное дело, выполняется исключительно по файловым записям (не зная ни о каких MFT), находит только одну запись. Если она одна - то почему счётчик равен двум? Понятно, что данные файла находятся в единственном экземпляре, но счётчик-то считает не количество копий данных, а количество файловых записей, на эти данные ссылающихся!

CaptainFlint
Я тебя спросил, что есть счетчик ссылок?
Ты ответил

Цитата:

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

А дальше...

KLASS

Цитата:

Я тебя спросил, что есть счетчик ссылок?

Сорри, я думал, из моего поста будет понятно.
Счётчик ссылок - это числовое поле, находящееся (по всей вероятности) внутри каждой MFT-записи, и содержащее количество файловых записей, ссылающихся на эту MFT-запись.
Т.е. каждая файловая запись в каталоге содержит имя файла и номер записи в MFT-таблице. Вот у каждой записи в MFT и указано, сколько всего существует на диске (во всех каталогах в сумме) файловых записей, ссылающихся на эту MFT-запись. Для большинства файлов этот счётчик равен 1 - сам файл, его "оригинальная" файловая запись. Если мы создаём жёсткую ссылку, счётчик автоматически увеличивается на 1. Если удаляем - уменьшается на 1. Если счётчик станет равным нулю, это будет означать, что мы только что удалили последнюю файловую запись, ссылающуюся на данную MFT-запись, а значит, к файлу больше невозможно обратиться (аналог потерянной цепочки в FAT), и его данные нужно удалять, чтобы не занимать впустую дисковое пространство.

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

KLASS
А-а Так и надо тогда говорить
WDX я пока не выкладывал, но для теста бросил на http://flint-inc.ru/Temp/NL_wdx.rar
То расширение, о котором я говорил, я что-то нигде не могу найти... В упор не помню, откуда я его взял, а здесь у меня его сейчас нет, только дома. Так что его я смогу выложить не раньше вечера.

CaptainFlint
Ничего я с твоим плагином не понял, установил... а где\как его запускать?
Собссно это и не важно... потом выложи, лучше, расширение для свойств файла.
Вернемся к нашим баранам.

Цитата:

Счётчик ссылок - это числовое поле, находящееся (по всей вероятности) внутри каждой MFT-записи, и содержащее количество файловых записей, ссылающихся на эту MFT-запись.

Честно гря предложение непонятно.
Числовое поле внутри записи MFT, содержит некое кол-во... не важно чего, допустим.
А вот последняя фраза

Цитата:

ссылающихся на эту MFT-запись

Как, что-то может ссылаться на MFT-запись? MFT-запись-это и есть сама ссылка на что-то, что находится на винчестере и называется данными (файлом). Файл не ссылается на MFT, а наоборот.

Цитата:

каждая файловая запись в каталоге содержит имя файла и номер записи в MFT-таблице

То что ты видишь в проводнике это не запись, это GUI. Сделано для твоего удобства, не более.

CaptainFlint
Есть консольная утилита от МС для сканирования дисков/папок и поиска ссылок. Бери тут http://www.microsoft.com/windows2000/techinfo/reskit/tools/new/hlscan-o.asp
(есть и поновее из rkt2003, но и эта сойдёт)

KLASS
Вот, для примера http://www.pcguru.ru/winxp/ntfs.shtml (см. про жёсткие ссылки)

KLASS

Цитата:

Как, что-то может ссылаться на MFT-запись? MFT-запись-это и есть сама ссылка на что-то, что находится на винчестере и называется данными (файлом). Файл не ссылается на MFT, а наоборот.

Я не зря написал про три уровня. См. ниже более детальное объяснение.

Цитата:

То что ты видишь в проводнике это не запись, это GUI. Сделано для твоего удобства, не более.

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


Пусть у нас на диске есть следующая структура файлов/каталогов:
\ (корень)
\123\
\123\file1.dat
\123\file2.dat
\456\
\456\link1.dat    <--- жёсткая ссылка на \123\file1.dat
\file3.dat

Тогда у нас MFT-таблица может выглядеть примерно так:
Номер записи Счётчик ссылок Адрес данных файла

CaptainFlint

Цитата:

Я не зря написал про три уровня. См. ниже более детальное объяснение.

Смотрю... Ниже ты сказал

Цитата:

Т.е. в каждом каталоге есть набор записей, а каждая запись является по сути ссылкой на MFT-запись

Неверно. Это и есть твоя ошибка. Смотри.
В каталоге нет никаких записей на записи в MFT (файлов). По другому, каталог-это и есть сама запись MFT. Еще по другому, возьмем твой пример, пока без хардлинка.
\ (корень)
\123\
\123\file1.dat
\123\file2.dat
\456\
\file3.dat
Шесть строчек - шесть записей в MFT, включая корневой каталог и вложенные в каталоги файлы.
По другому, файл file1.dat (и другие) имеют одну собственную запись и в ней прописано именно, как ты и написал
\123\file1.dat
и каталог 123 тоже имеет свою, одну запись, она выглядит так
\123
и т.д.
Но, если глыбже копать, то, разумеется, эти ссылки ничего общего не имеют с данными на диске, они представлены лишь для юзера (как ты их видишь в проводнике или в поиске). На самом деле NTFS адресуется к какому-то файлу (данным на диске), используя LCN (Logical Cluster Numbers) и.т.д. Об этом пока не будем, а то и так запутались...
Т.е. ты представил MFT, как корневой каталог, из которого идут ссылки на другие файлы\каталоги. На самом деле это не так. Как корневой каталог, так и любой другой каталог, либо файл, имеют собственную запись, но только одну и никаких внутренних (с корневого каталога, или любого другого) ссылок на конкретный файл просто нет.
Smitis
Спасибо за ссылку...

KLASS

Цитата:

Ничего я с твоим плагином не понял, установил... а где\как его запускать?

Ой, что-то я пропустил эту твою фразу... Извиняюсь.

Во-первых, нужен Тотал версии 6.5. В нём открываешь диалог настроек, там страницу Plugins, в пункте WDX жмёшь кнопку Configure, там добавляешь плагин кнопкой Add.
Дальше идёшь на страницу Custom Columns, New, Add column, справа у появившейся строки жмёшь плюсик. В появившемся меню выбираешь nl_wdx->Info (number). Жмёшь везде OK. Теперь в панели нажимаешь Shift+F1, выбираешь самый нижний пункт (если ты его не называл по-своему, у него будет имя "Info (number).."). Всё, у каждого файла справа показано количество жёстких ссылок.
Также можно открыть диалог поиска файлов (Alt+F7), выбрать диск, на вкладке Plugins задать правило (Plugin: nl_wdx, Property: Info (number), OP: =, Value: 2), не забыть включить галочку "Search in plugins" и жать "Поиск" - будут найдены все файлы, имеющие две жёсткие ссылки. Их должно быть чётное число, поскольку все они должны разбиваться на пары, ссылающиеся на одну MFT-запись.

Добавлено:

Цитата:

В каталоге нет никаких записей на записи в MFT (файлов). По другому, каталог-это и есть сама запись MFT.
.......

Не понял. А как же тогда осуществляется навигация по каталогам? Я вижу два варианта:
1. Для того, чтобы получить содержимое каталога, надо прочесать всю MFT, выбрав только те файлы, которые принадлежат данному каталогу. Понятно, что чушь полнейшая, ибо тормоза были бы немеряные.
2. Полный список файлов, находящихся в каталоге, хранится в каком-то месте. Этим место не может быть сама MFT, поскольку тогда бы количество файлов внутри каталогов было бы ограниченно довольно небольшим числом, а мы знаем, что это не так. Либо вариантом могло бы быть выделение для каталогов переменного числа MFT-записей, чтобы хранить всю информацию, неоптимальное решение, поскольку вызывает фрагментацию самой MFT. Гораздо логичнее хранить каталог в виде обычного файла, как это делалось в FAT.

И если моё представление оказалось в корне неверным, то что же такое тогда счётчик ссылок? Это же не я выдумал, это вполне объективная величина, увеличивающаяся при создании ссылок и уменьшающаяся при их удалении. Её можно узнать не какими-то супер-хитрыми низкоуровневыми функциями, а самым что ни на есть обычным WinAPI:
GetFileInformationByHandle(...), в возвращаемой структуре есть поле nNumberOfLinks. Цитата из MSDN:
Цитата:

Specifies the number of links to this file. For the FAT file system this member is always 1. For NTFS, it may be more than 1.

Тогда что же это такое? И почему в нормальной ситуации эта величина ведёт себя в точности так, как я описывал выше?

CaptainFlint
Да шут с ним с коммандером, тем более, у меня версия 6.01 я просто подумал, что у тебя есть утиль, которая кажет некий
Цитата:

Счётчик ссылок

... если этого нет, мне без надобности... Ты понял про NTFS?


Добавлено:
CaptainFlint

Цитата:

Полный список файлов, находящихся в каталоге, хранится в каком-то месте.

Нет... каждый файл имеет свою, собственную запись

Цитата:

И если моё представление оказалось в корне неверным, то что же такое тогда счётчик ссылок?

Я бы то же хотел об этом узнать (см. выше)...

Цитата:

а самым что ни на есть обычным WinAPI

Я в программировании не шарю... я пользователь, как ты выше и выразился

Цитата:

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

Цитата:

И почему в нормальной ситуации эта величина ведёт себя в точности так, как я описывал выше?

В какой ситуации? Где ты эту величину видишь, чтобы я понял о чем речь...

CaptainFlint правильно представляет себе каталоги NTFS, так же написано и у Русиновича.

Тот счетчик ссылок, который показывает TC, хранится в MFT файла и может не соответствовать действительному числу ссылок не этот файл. chkdsk, наверное, это и не проверяет.

Попробуй посмотреть на диск с Runtime Disk Explorer for ntfs (runtime.org). Там можно найти номер MFT твоего файла, запустить поиск этого числа (оно 64-битное, так что должно найти не так уж много) по всему диску и посмотреть, где оно найдется

Есть ntfsinfo для linux, может, оно умеет показывать, на какие MFT есть ссылки в каталогах

Во, просканировал диск прогой, которую посоветовал Smitis. Как я и ожидал, вывелось следующее:

Цитата:

ID: 0x15000000000485 - Hard Links Count: 2 - Missing: 1
  Creation Time: 10/23/2004 03:27:35
  Last Access Time: 10/23/2004 03:27:35
  E:\file.dat

Для примера вот вывод для "нормальной" жёсткой ссылки:

Цитата:

ID: 0x4000000006a43 - Hard Links Count: 3 - Missing: 0
  Creation Time: 11/20/2004 18:58:26
  Last Access Time: 11/20/2004 18:58:26
  E:\RECYCLER\NPROTECT\00001924.dat
  E:\RECYCLER\NPROTECT\00002357.dat
  E:\file1.dat

Т.е. как видим, если счётчик равен N, то на диске найдётся ровно N файлов, ссылающихся на MFT-запись с тем же идентификатором.

По поводу того расширения оболочки: оказалось, что этот пример я взял из MSDN, поэтому просто выкладываю архив себе на сайт:
http://flint-inc.ru/Temp/Source.zip
Кстати, я и правда забыл про Far - он умеет отображать количество жёстких ссылок.

Теперь насчёт структуры файлов и каталогов: я нашёл подтверждение своей точки зрения в том же MSDN. А именно: там сказано, что содержимое небольших файлов и каталогов хранится непосредственно в самое MFT-записи, а большие - во "внешнем пространстве". Под содержимым каталогов здесь понимается по сути список файлов, которые в этом каталоге хранятся. Далее, файл рассматривается как набор атрибутов. Атрибутами считаются даже такие вещи, как имя файла и его данные. Некоторые атрибуты хранятся прямо в MFT-записи, остальные - во "внешнем пространстве". Так вот, в число атрибутов входит "link count" - счётчик ссылок, о котором я и говорил всё это время.
Насчёт детальной структуры каталогов, к сожалению, ничего найти не удалось. По всей видимости, это закрытая информация. Но на самом деле, не так уж и важно, что конкретно хранится в записях внутри каталогов - ссылки на MFT или непосредственно ссылки на данные файла, или ещё что-то. Главное, что при создании жёсткой ссылки (т.е. ещё одной записи внутри какого-то каталога, указывающей на уже существующий файл) этот самый счётчик ссылок увеличивается, а при удалении жёсткой ссылки - уменьшается.

CaptainFlint
Все верно, признаю, был не прав. Только, покажи еще, что у тебя прописала утиль в первом случае, после Summary:

Цитата:

Так вот, в число атрибутов входит "link count" - счётчик ссылок, о котором я и говорил всё это время.

Именно так и атрибут этот обзывается $STANDARD_INFORMATION, содержащий, по мимо прочей инфы, число каталогов, ссылающихся на данный файл, по другому, счетчик хардлинков. Равно, при создании жесткой связи, создается и второй атрибут $FILE_NAME... на чем я собссно и "попал" (подумал, что этого достаточно) и забыл главное правило, что через жесткие связи можно ссылаться на один и тот же файл именно по нескольким путям. Т.е. с файлом на диске связано несколько путей, взависимости от количества хардлинков.

Цитата:

Насчёт детальной структуры каталогов, к сожалению, ничего найти не удалось.

У них есть свои атрибуты (которых нет у файлов) которые и используются под имена файлов находящихся в данном каталоге (для больших каталогов, имена файлов распологаются в индексных буферах). Там же находится сопоставление VCN-LCN, для мгновенного поиска данных на винте. Что и делает NTFS более привлекательной, нежели FAT, т.е. обращение к данным идет не через первый кластер файла, а сразу в "нужное" место файла.
Есть еще одна, чудная утиль из OEM Support Tools 2000 для просмотра MFT "nfi.exe", ее можно найти и отдельно, через поиск по ftp.

Цитата:

Только, покажи еще, что у тебя прописала утиль в первом случае, после Summary

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

Цитата:

Summary:
Files scanned: 104422
Physical files with more than one name: 31
Hard links: 59

Warning: 17 files or directories could not be scanned.
Check E:\HLScan.err for details

Хардлинков должно быть, минимум, в два раза больше, т.е. 62... сижу ковыряю\перемещаю файлы и никак хардлинки не падают.
Ответа так и не нашли... Мдя...

Цитата:

Хардлинков должно быть, минимум, в два раза больше

Значит, у него есть ещё потерянные линки. У меня подозрение, что где-то просто нет доступа к файлам, причём даже не только для текущего пользователя, а для SYSTEM.
Можно попробывать выставить права на весь диск через properties / security / advanced с галочкой "replace permission entries for all child objects..."

Блин, кажется, я понял, "где собака порылась"! Smitis, ты почти прав. Прога же выдала мне:
Цитата:

Warning: 17 files or directories could not be scanned.

В ERR-файле написано, что нет доступа к куче файлов с именами типа E:\RECYCLER\NPROTECT\00002784.. - именно с двумя точками! Нортон изредка грешит этим, создаёт такие имена, к которым нормальными средствами доступиться не получается. Уверен, что все отсутствующие ссылки прячутся именно в таких именах! Домой приду, обязательно проверю.

Да, проверил - так и оказалось Прибить бы этот Нортон, да альтернативы нормальной нема...
Имена оказались, правда, не с двумя точками, а с одной, но эта точка входила в имя, а вторая точка появилась, видимо, как разделитель имени и (пустого) расширения. Сейчас просмотрел в WinHex-е подобные файлы, в одном из них увидел прописанное имя того файла, о котором говорил в самом первом посте, да и содержимое было то же самое. Хакнул тем же WinHex-ом файловую запись, забив эту точку символом "0", перезагрузился (винда, похоже, файловые записи кэширует, поскольку без перезагрузки изменений на диске не было видно), удалил этот файл, у которого теперь стало доступное имя - и всё! Количество ссылок у того первоначального файла стало 1.

Спасибо всем за помощь и советы!

Еще, как вариант.
К примеру, имею каталог с туевой кучей файлов, один с именем

Цитата:

C:\Documents and Settings\!\My Documents\Translation\Deja Vu X\KB\RUS\872769 - Не удается настроить параметры брандмауэра или центра безопасности на входящем в сеть Windows Small Business Server 2003 клиентском компьютере под управлением XPSP2_8183018.htm

Переименовываю каталог Translation в Translation1234567890123 и файл уже имеет длинные путя и, соответственно, не открывается. При запуске hlscan.exe один хардлинк у этого файла тю-тю. Правда, если вернуть имя каталога взад, файл "вернется" вместе с хардлинком. Между переименованиями каталога запускал CHKDSK, результат тот же.

подскажите пожалуйста:
есть ли в Windows нормальный способ создания жестких ссылок?

если нет, то чем можно делать?

eugrus
Нормального, входящего в состав винды, нету. Можно воспользоваться либо Far Manager'ом (Alt+F6), либо Total Commander + NTFS Links.

eugrus
fsutil hardlink create

Некоторые програмки по теме, для Windows:

Duplicate File Hard Linker
PHM PowerToys
HardLinker

Есть еще програмка Hard Link Magic, только сайт разработчика сейчас больше не работает, и мне только версию 1.07 удалось найти, тогда как есть и 1.08, - только ссылки для закачки оной, мне не попадалось...