Total Commander

Не в курсе, о чём ты. У Sym/RP такие есть?

Я имел в виду ситуации, когда ссылка ведёт к объекту, в пути к которому есть другие ссылки. Например, D:\Path\Lnk1 ссылается на D:\Lnk2\Dir1, где D:\Lnk2 в свою очередь ссылается ещё на что-то.

Что за запуск? Удаление одноимёнок без проверки вредно. Я же выше объяснял. Ссылка может вести на другой источник. Это не будет равноценной заменой.

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

Какой объект? Одноимённый? Разберись в терминах.

Термины порой и правда сбивают с толку. Одноимёнка одна чего стоит, не говоря уже об имеющейся одноимёнке.

Автопереименовывать существующие объекты не имеет смысла (хотя в ряде ренеймеров такая опция имеется).

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

где D:\Lnk2 в свою очередь ссылается ещё на что-то.

Это нас должно волновать? Ссылка должна вести на тот объект, для которого создавалась. Так и происходит с LinkTarget.

В случае, когда пользователь сначала сам разруливает конфликты, используя силу своего интеллекта.

Этот случай совершенно не потребен, когда речь идёт о десятках, сотнях и тысячах выбранных объектов, в т. ч. в режиме без подкаталогов.

Одноимёнка одна чего стоит, не говоря уже об имеющейся одноимёнке.

Нашёл к чему придраться. Одноимёнка — одноимённый объект (папка/файл). Тебе это разъяснять надо? Серьёзно?
Да и по контексту там всё абсолютно ясно.

В самом тотале есть такое, поэтому и уточняю.

Знаю. Никогда не пользовался — не понимаю, зачем. Только проблемы создаёт.

к имени добавляется суффикс со счётчиком таким образом, чтобы конфликт не возникал, затем ссылка наконец создаётся.

Да я прекрасно понимаю, как переименовываются имеющиеся одноимённые объекты. Об этом варианте больше не говорим.

Это нас должно волновать? Ссылка должна вести на тот объект, для которого создавалась. Так и происходит с LinkTarget.

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

Этот случай совершенно не потребен, когда речь идёт о десятках, сотнях и тысячах выбранных объектов, в т. ч. в режиме без подкаталогов.

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

по факту это один объект, но непосредственные ссылки разные.

Объясни, как это будет мешать системе автопереименования, если будет раскрываться только рассматриваемая ссылка? По мне, более чем досточно проверки по первому возращаемому пути (без потенциальной цепочки). Можно, конечно, всю цепочку проверять в цикле, но, боюсь, это может существенно сказаться на скорости.

А мне очень кажется, что в таких ситуациях нужен реально инструмент синхронизации

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

NTLinksMaker Build 432:
* исправлена обработка относительного пути назначения

wdx_NTLinks Build 270:
+ поле File_Type
* ошибка определения реального пути в случае относительной ссылки

MVV писал(а):исправлена обработка относительного пути назначения

За пару месяцев можно было бы и остальное исправить.

А что ещё не исправлено из того, что должно быть исправлено?

Случаи с выше обсуждаемой руганью, вестимо.

Не припомню там про исправления, только про новый функционал, который я счёл неуместным.

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

Автопереименование будет, руки не дошли до него. А найденные баги оставлять на потом не хотелось.

Ругань не всякая требует исправления, а лишь конструктивная. Так или иначе, исправлением я бы добавление нового функционала, не заявленного в описании, называть не стал.

Там ещё про пропуск речь велась. С ним тоже хотелось бы разрешить ситуацию.

У программ может быть коструктивная ругань? Вот это поворот!
А вот обоснования в отношении *\папка\*.* были выдвинуты вполне конструктивные, и никак далее не опровергнуты.

Пропуск дубликатов ссылок обещать не буду, муторное дело это.

А касаемо *\папка\*.* - я не считаю выдвинутые обоснования конструктивными, т.к. убедительных аргументов в пользу необходимости такого извращения и осмысленных примеров не было.

Прежде всего речь шла о тихом режиме после диалога. Далее пошли уже детали. Ты же писал, что можешь отличать хардлинки по индексу. Можно хотя бы для них сделать пропуск?
Ну, и разумеется, замену симлинка и пропуск при наличии нессылочной одноимёнки.

Удивительно, что создание подпапки ты называешь извращением. Это вполне классическая ситуация сродни распаковке архивов в создаваемые подпапки в структуре каталогов. Ничего тут извращенского нет априори.

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

На "нессылочной одноимёнке" завис... Имеешь в виду пропуск создания ссылки, если на месте создаваемой ссылки существует файл/папка с тем же именем и это не ссылка? Но если это ссылка, хочешь, чтобы заменялась? Ощущение, что мы повторяем всё по второму кругу...

Ещё раз, если место создаваемой ссылки занято, возможны три действия: пропуск, замена или переименование. Безусловный пропуск - тут всё тривиально и предсказуемо. Безусловное переименование - тут тоже. С условными сложнее. Место может быть занято ссылкой, файлом или папкой. Если файлом, можно сравнить индексы и заменить или переименовать, но если создаётся ссылка на ссылку, индекс ничего не даст. Если папкой, только переименовать. Если ссылкой, опять же можно сравнить целевые пути и заменить или переименовать.

В диалоге я готов добавить комбобокс с поведением при конфликтах и соответствующий ключ командной строки:
1. Запрашивать действие (как сейчас),
2. Пропускать все,
3. Автопереименовывать все.

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

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


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