Если кол-во жёстких ссылок в одной папке зашкаливает за пару сотен, то, конечно, пользоваться отсевом из выделенных файлов, отсортированных по символьному пути, будет несколько долго, а уж есть операция неоднократная, то совсем не вариант. Тогда можно скрипт сделать: подсчёт размера всех файлов, не имеющих дубликатов + суммы файлов дубликатов, каждый из которых будет делиться на кол-во реальных ссылок на каждый.GGS писал(а):Добавлю, что этот файл в папках Б и В может иметь совершенно разные имена. Так же как и в одной папке.
Как подсчитать размер папки с учетом ссылок?
Модераторы: d-view, Моторокер, Avada, CaptainFlint, Nik
Что ты вкладываешь в понятие "символьный путь"? И чем он помогает отсеивать жесткие копии? Жесткие копии можно отсеять исключительно по NTFS-индексу файла, который у них одинаков.
А делить размер на число жестких ссылок я хотел было предложить еще в первом своем посте этой темы, но такой способ будет давать неверный результат, если у файла есть жесткие копии вне рассматриваемого каталога - ведь такие доли размеров не будут учтены.
А делить размер на число жестких ссылок я хотел было предложить еще в первом своем посте этой темы, но такой способ будет давать неверный результат, если у файла есть жесткие копии вне рассматриваемого каталога - ведь такие доли размеров не будут учтены.
Путь нахождения самой ссылки, а не исходного файла.MVV писал(а):Что ты вкладываешь в понятие "символьный путь"?
Он не помогает отсеивать, по нему можно осуществить сортировку выделенных по реальному пути файлов, а после из отсортированных выделенных заспэйсить дубликаты.MVV писал(а):И чем он помогает отсеивать жесткие копии?
Либо по индексу, всё равно.MVV писал(а):Жесткие копии можно отсеять исключительно по NTFS-индексу файла, который у них одинаков.
Не понял, а зачем вдруг автору понадобится учитывать ссылки вне рассматриваемого каталога?MVV писал(а):но такой способ будет давать неверный результат, если у файла есть жесткие копии вне рассматриваемого каталога - ведь такие доли размеров не будут учтены.
Ты наверное плохо понимаешь, что такое жесткая ссылка. Жесткие копии файла - это равноправные указатели на физический файл в недрах файловой системы (любой файл - это пара, состоящая из содержимого файла и одной жесткой ссылки) - можно сказать, что в папках ты видишь не файлы, а жесткие ссылки на них. Имея две жесткие копии невозможно сказать, какая из них важнее, также как невозможно определить, какая из них была создана ранее. И единственный способ определить, что оба файла являются ссылками на один объект - сравнить идентификаторы. Путь у каждой жесткой ссылки на файл один, и это путь к ссылке.Flasher писал(а):Путь нахождения самой ссылки, а не исходного файла.
Думаю, прочитав вышенаписанное в этом посте ты поймешь несостоятельность данной идеи. Отсеить мы ничего не можем, нам нужно просуммировать размеры всех файлов в папке, при этом не суммируя более одного раза файлы с одинаковыми индексами.Он не помогает отсеивать, по нему можно осуществить сортировку выделенных по реальному пути файлов, а после из отсортированных выделенных заспэйсить дубликаты.
Представь, что файл имеет несколько ссылок внутри каталога, и несколько - вне его. А ты хочешь определить, сколько весит каталог, то есть для этого нужно каждый уникальный (по идентификатору) файл в нем подсчитать ровно 1 раз. Твоим способом ты не получишь полный вес файла, так как часть ссылок не будет учтена при суммировании. Арифметика тут несложная.Flasher писал(а):Не понял, а зачем вдруг автору понадобится учитывать ссылки вне рассматриваемого каталога?
Если бы она состояла из содержимого, то и размер бы на носителе увеличивался бы вдвое. Тогда и смысл в жётских ссылках бы пропадал.MVV писал(а):любой файл - это пара, состоящая из содержимого файла и одной жесткой ссылки
Если их более двух, то да, а если две то можно, узнав реальные и символьные пути каждого.MVV писал(а):также как невозможно определить, какая из них была создана ранее.
Тогда что по твоему символьный путь и что реальный? Ты вообще список встраиваемых колонок в NLInfo видел?MVV писал(а):Путь у каждой жесткой ссылки на файл один, и это путь к ссылке.
Отсев предлагался пофайловый, т.е. снятие выделения с дубликатов.MVV писал(а):Отсеить мы ничего не можем, нам нужно просуммировать размеры всех файлов в папке, при этом не суммируя более одного раза файлы с одинаковыми индексами.
Чего чего? Как это не будет? Закинул две ссылки на один файл размером 1 Мб в одну папку, и ещё одну ссылку на него в другую. Выделяю в первой папке два файла, сумма = 2 Мб, делю на 2, получается 1 Мб. Ну и какая у тебя тут другая может быть арифметика?MVV писал(а):Твоим способом ты не получишь полный вес файла, так как часть ссылок не будет учтена при суммировании.
С какой стати размер увеличивался бы? При создании жесткой ссылки создается такая же ссылка на то же содержимое файла. Получается, что у файла уже две точки доступа. Это как будто назначить логическому диску две буквы - диска от этого не станет два.Если бы она состояла из содержимого, то и размер бы на носителе увеличивался бы вдвое. Тогда и смысл в жётских ссылках бы пропадал.
Ты так и не объяснил, что понимаешь под символьными путями. Это какое-то абсурдное понятие, которое не имеет отношения к жестким ссылкам (hardlinks). И на все попытки объяснить тебе суть жестких ссылок ты продолжаешь гнуть свою кочергу.Если их более двух, то да, а если две то можно, узнав реальные и символьные пути каждого.
Представь себе, видел. Моя NTLinks предоставляет больше колонок, если ты заметил, включая индекс файла - единственное поле, способное помочь при работе с жесткими ссылками.Ты вообще список встраиваемых колонок в NLInfo видел?
Ручками пройти десяток тысяч файлов и поснимать выделение с дубликатов?Отсев предлагался пофайловый, т.е. снятие выделения с дубликатов.
Интересно, с какого это ты делишь на 2, когда у тебя счетчик жестких ссылок покажет минимум 3?Чего чего? Как это не будет? Закинул две ссылки на один файл размером 1 Мб в одну папку, и ещё одну ссылку на него в другую. Выделяю в первой папке два файла, сумма = 2 Мб, делю на 2, получается 1 Мб. Ну и какая у тебя тут другая может быть арифметика?
Кидаешь две ссылки на метровый файл в папку А, и две в папку Б - итого 4 жестких копии. А теперь считаешь размер папки А по твоей методике. Получаешь 1/4+1/4=0.5, а должен получить 1, так как файл весит метр!
Кстати, как ты создаешь свои жесткие ссылки? Я лично создаю их через NTFSLinks.
Вот именно что ссылка на содержимое, а не само содержимое, это абсолютно разные вещи.MVV писал(а):При создании жесткой ссылки создается такая же ссылка на то же содержимое файла.
Ты МНЕ это рассказываешь?..MVV писал(а):Это как будто назначить логическому диску две буквы - диска от этого не станет два.
Как это не объяснил? Может это ты не удосужился прочесть?MVV писал(а):Ты так и не объяснил, что понимаешь под символьными путями.
Я просто в твоих объяснениях ничего нового для себя не прочёл, кроме некоторых нестыковочных моментов.MVV писал(а):И на все попытки объяснить тебе суть жестких ссылок ты продолжаешь гнуть свою кочергу.
Больше чем что или у кого?MVV писал(а):Моя NTLinks предоставляет больше колонок, если ты заметил, включая индекс файла - единственное поле, способное помочь при работе с жесткими ссылками.
Даа, с вниманием у тебя явно не лады. Вернись к посту, где я писал GGS, открыл Америку, называется.MVV писал(а):Ручками пройти десяток тысяч файлов и поснимать выделение с дубликатов?
С какой это стати, если путь вне надлежащей для подсчёта папке учитываться не будет?MVV писал(а):Интересно, с какого это ты делишь на 2, когда у тебя счетчик жестких ссылок покажет 3?
Это явно не моя методика. Ты меня с собой случем не спутал?MVV писал(а):А по твоей методике. Получаешь 1*0.25+1*0.25=0.5
Если же исходного файла в этой папке не будет, то скрипт должен отсеять все файлы, реальные пути которых не ведут в родительских каталог.
Ну какая разница, кто через него, кто через CreateHardLink.wcx.MVV писал(а):Кстати, как ты создаешь свои жесткие ссылки? Я лично создаю их через NTFSLinks.
А покажи мне хотя бы одно место, где я эти понятия путал. Я лишь говорю, что каждый файл имеет минимум одну жесткую ссылку - и эта ссылка - сам файл, который ты видишь в папке. В таблице файлов (MFT) для каждого индекса хранится инфа о том, как получить доступ к содержимому (неважно, где-то на диске это содержимое или прямо в MFT). А далее в каталоге, где ты создаешь файл, создается запись, содержащая простейшие атрибуты файла и индекс в MFT, по которому искать содержимое файла. И каждая жесткая ссылка - это такая запись в каталоге. Сколько бы их ни было, где бы они не находились, друг о друге они не знают ничего кроме их общего числа - система удаляет содержимое файла, когда число жестких ссылок на него уменьшается до нуля.Вот именно что ссылка на содержимое, а не само содержимое, это абсолютно разные вещи.
Вот и подумай теперь, откуда арифметика. Если у меня 2 жестких ссылки на файл в одной папке и 2 в другой - внимание, вопрос на миллион, сколько всего ссылок? Правильно, 4. И NL_Info, как и NTLinks, тебе скажут, что ссылок 4. А если ты имеешь в виду не число жестких ссылок, возвращаемое плагинами, а число дубликатов индексов в пределах рассматриваемого каталога - так и скажи, тогда математика будет иная. Но тогда твой способ абсолютно ничем не отличается от моего, предложенного в самом начале темы (и более-менее подробно описанного, например, тут) - суммировать файлы, запоминая индексы уже просуммированных, чтобы в дальнейшем для каждого следующего файла проверять, был ли посчитан файл с таким индексом.
Почему же, я все время говорю о поле, возвращаемом плагинами.Или ты о каком-то чудо-счётчике, о котором тут никто представления не имеет?
Как это не объяснил? Может это ты не удосужился прочесть?
То бишь сам файл + 3 ссылки?
Если я должен был прочесть, что это Путь нахождения самой ссылки, а не исходного файла, то это не поможет тебе ничем. Для каждой жесткой ссылки символьный или реальный путь к ней - это и есть путь к ссылке, все ссылки равноправны, нельзя сказать, что исходный файл по ссылке aaa.bbb лежит под именем bbb.ccc. Можно лишь сказать, что файлы aaa.bbb и bbb.ccc являются жесткими копиями, что означает, что их записи в каталогах (которые по существу и являются жесткими ссылками) ссылаются на один элемент таблицы файлов. А символические ссылки на файл/папку, введенные в висте, а также точки соединения (junction) - это ссылки, которые ссылаются на объект каталога, а не на объект таблицы файлов, поэтому для них понятие реального пути имеет прямой смысл.Если же исходного файла в этой папке не будет, то скрипт должен отсеять все файлы, реальные пути которых не ведут в родительских каталог.
Аж интересно стало, о каких конкретно колонках ты говоришь.Тогда остальные колонки там так, для красоты прикручены?
Пожалуйста >MVV писал(а):А покажи мне хотя бы одно место, где я эти понятия путал.
MVV писал(а):любой файл - это пара, состоящая из содержимого файла и одной жесткой ссылки
А я разве не об этом пишу?MVV писал(а):А если ты имеешь в виду не число жестких ссылок, возвращаемое плагинами, а число дубликатов индексов в пределах рассматриваемого каталога - так и скажи
Это ты кого цитируешь?MVV писал(а):Почему же, я все время говорю о поле, возвращаемом плагинами.Или ты о каком-то чудо-счётчике, о котором тут никто представления не имеет?
А я разве искал помощи?MVV писал(а):Если я должен был прочесть, что это Путь нахождения самой ссылки, а не исходного файла, то это не поможет тебе ничем.
Вот теперь картина начинает вырисовываться. Символьные пути для символьных ссылок. Проще было сразу так написать.MVV писал(а):А символические ссылки на файл/папку, введенные в висте, а также точки соединения (junction) - это ссылки, которые ссылаются на объект каталога, а не на объект таблицы файлов, поэтому для них понятие реального пути имеет прямой смысл.
Целевой объект.Естественный/Символьный, Реальный путь.Естественный/Символьный, тип символьной ссылки, Корректная ссылка, ..MVV писал(а):Аж интересно стало, о каких конкретно колонках ты говоришь.
Ну, я вижу, ты уже разобрался, что далеко не для каждого типа ссылки эти поля имеют смысл.Целевой объект.Естественный/Символьный, Реальный путь.Естественный/Символьный, тип символьной ссылки, Корректная ссылка, ..
Не вижу, где я в этом предложении спутал содержимое со ссылкой на содержимое, если я русским языком написал, что файл представляет собой само содержимое и жесткую ссылку на это содержимое.Пожалуйста >
Ты думал об этом. И думал, что пишешь об этом. Но не писал явно об этом. А "кол-во реальных ссылок на каждый файл" - это в контексте темы о жестких ссылках в первую очередь число жестких ссылок файла, а не число жестких ссылок файла в пределах конкретной папки.А я разве не об этом пишу?
Извините, RTFM.Вот теперь картина начинает вырисовываться. Символьные пути для символьных ссылок. Проще было сразу так написать.
Тебе не один раз пытались объяснить, что жесткие ссылки равноправны. А "символьный путь" в рамках NTLinks - это тот же реальный путь файла, но без замены идентификатора тома буквой, ассоциировать символьный путь с символическими ссылками не стоит.
А если по теме - упорядоченный массив элементарно строится с помощью массива данных и массива индексов, хотя тут возможно хватит и просто массива данных, так как элементы - всего лишь 64-битные числа. А нам нужен бинарный поиск элемента в массиве, иначе поиск индекса потребует катастрофически больше времени, если у нас будет несколько тысяч файлов. Самой нудной частью программы будет та, которая будет парсить список, переданный тоталом, и искать все файлы, удовлетворяющие строчкам списка.
Вот это и противоречит моим словам о том, что содержимое он представлять не может, иначе бы размер увеличивался, а ты просто повторяешься и удивляешься своим же словам.MVV писал(а):что файл представляет собой само содержимое и жесткую ссылку на это содержимое.
Это легко можно было понять из поста о несложной арифметике.MVV писал(а):Ты думал об этом. И думал, что пишешь об этом. Но не писал явно об этом.
В справке по NTLinks дословно об этом не написано. Поэтому не извиню.MVV писал(а):Извините, RTFM.
Ты не из королевской знати случаем будешь, во множественном числе о себе говорить?MVV писал(а):Тебе не один раз пытались объяснить, что жесткие ссылки равноправны.
И где я могу эту замену идентификатора тома буквой в реальном пути увидеть?MVV писал(а):А "символьный путь" в рамках NTLinks - это тот же реальный путь файла, но без замены идентификатора тома буквой, ассоциировать символьный путь с символическими ссылками не стоит.
То, что ты видишь в папке - это еще не файл, это лишь жесткая ссылка. А файл - это эта жесткая ссылка плюс то, на что она ссылается - на содержимое (плюс атрибуты, разрешения, дополнительные потоки и прочий бред). Но ничто не мешает файлу иметь несколько жестких ссылок.Вот это и противоречит моим словам о том, что содержимое он представлять не может, иначе бы размер увеличивался, а ты просто повторяешься и удивляешься своим же словам.
А почему я обязан описывать то, чего полно в интернете, в справке к NTLinks? Справка по NTLinks описывает функции плагина, а не особенности жестких и символических ссылок.В справке по NTLinks дословно об этом не написано. Поэтому не извиню.
Если ты внимательно просмотришь тему, ты увидишь, что не я один вхожу в число тех, кто пытался открыть тебе глаза на сущность жестких ссылок. И твои остроты тут неуместны.Ты не из королевской знати случаем будешь, во множественном числе о себе говорить?
Первые два символа реального пути - это буква, ассоциированная с томом, и двоеточие.И где я могу эту замену идентификатора тома буквой в реальном пути увидеть?
А вот если ты себе из папки с помощью команды mountvol (или просто из диспетчера дисков) сделаешь точку подключения (монтирования) тома, то для каждого файла в этой папке поле реального пути NTLinks будет возвращать читабельный путь, а поле символьного пути - путь, начинающийся с идентификатора тома (например, \\?\Volume{cd6ccf88-d915-11db-ae94-008048198c56}\).
Хоть бы раз спасибо сказал вместо надменного посыла.Я без всяких объяснений прекрасно знал об этом. Так что зря время тратил.
Что же ты, если прекрасно все знал, путал типы ссылок и привязывал жесткие ссылки к реальным/символическим путям? Можешь не отвечать, вопрос риторический. Я не собираюсь больше тут флейм разводить.
Как это вообще относится к цитированным словам? Всё что ты написал итак вполне очевидно тем, кто с ж.с. имел дело.MVV писал(а):То, что ты видишь в папке - это еще не файл, это лишь жесткая ссылка. А файл - это эта жесткая ссылка плюс то, на что она ссылается - на содержимое (плюс атрибуты, разрешения, дополнительные потоки и прочий бред). Но ничто не мешает файлу иметь несколько жестких ссылок.
Поэтому правильно выбирай выражения, не RTFM, а тогда уж STFW, RTFW, UTFG.MVV писал(а):А почему я обязан описывать то, чего полно в интернете
Кроме тебя мне с пеной у рта тут ничего никто не доказывал, и я говорил конкретно о равноправии ссылок и ни о чём больше. Поэтому говорить от лица всех несколько невежливо, согласись.MVV писал(а):Если ты внимательно просмотришь тему, ты увидишь, что не я один вхожу в число тех, кто пытался открыть тебе глаза на сущность жестких ссылок. И твои остроты тут неуместны.
Ну, во-первых, это никакой не посыл, и время ты тратил зря далеко не на всё, как нужно понимать, исходя их контекста приведённой цитаты, а именно касаемо равноправия жестких ссылок. Во-вторых, спасибо я говорю в случае, когда информация лично для меня несёт существенную пользу, говорить спасибо за лекции с нравоучительным подтекстом несколько не в моих интересах.MVV писал(а):Хоть бы раз спасибо сказал вместо надменного посыла.
Опять ты передёргиваешь, всё я точно не знал, и ты внёс определённую ясность, не без воды, к сожалению. Типы ссылок я не путал, это уже твои домыслы.MVV писал(а):Что же ты, если прекрасно все знал, путал типы ссылок и привязывал жесткие ссылки к реальным/символическим путям? Можешь не отвечать, вопрос риторический.
Ну наконец-то, а то я уж и надеяться подперестал на это. Я бы и не начинал весь этот хоровод, зная во что он превратится..MVV писал(а):Я не собираюсь больше тут флейм разводить.