Total Commander

Не планируется ли юникодной версии NTFS Links? Насколько понимаю, поменять нужно будет очень мало. И преобразовывать пути в юникод не придётся при создании точки соединения. Кстати, с учётом того, что NTFS есть только в Windows NT, не-юникодную версию вообще можно убрать:)

MVV писал(а):Не планируется ли юникодной версии NTFS Links?

Планируется непременнейшим образом. Конкретно юникодная сделана давным-давно чуть менее, чем полностью, просто я там начал добавлять поддержку вистовых симлинков, а оказалось, что их без повышения привилегий не создашь (а повышение привилегий — это до ужаса муторная вещь

).

MVV писал(а):Кстати, с учётом того, что NTFS есть только в Windows NT, не-юникодную версию вообще можно убрать

Само собой. Просто текущую заменю на новую.

[off]
Вообще, я решил окончательно забить на поддержку Win9x. Единственное исключение — NoClose Replacer, да и то лишь потому, что для остальных мои программ/плагинов, если кому сильно надо, можно взять старую версию, а у NoClose старая версия с новым Тоталом работать не сможет.
[/off]

CaptainFlint писал(а):Планируется непременнейшим образом. Конкретно юникодная сделана давным-давно чуть менее, чем полностью, просто я там начал добавлять поддержку вистовых симлинков, а оказалось, что их без повышения привилегий не создашь (а повышение привилегий — это до ужаса муторная вещь ).

Ну не так и муторно повысить привилегии. Привилегия всего одна требуется. Вот код для получения (писал для NTLinks):

Код: Выделить всё

bool GetCreateSymlinkPrivileges() {
	HANDLE hToken; TOKEN_PRIVILEGES tp;
	bool result=0;

	if (OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES, &hToken)) {
		tp.PrivilegeCount=1;
		tp.Privileges[0].Attributes=SE_PRIVILEGE_ENABLED;
		if (LookupPrivilegeValue(0, SE_CREATE_SYMBOLIC_LINK_NAME, &tp.Privileges[0].Luid)) {
			result=AdjustTokenPrivileges(hToken, 0, &tp, sizeof(TOKEN_PRIVILEGES), 0, 0)!=0 && !GetLastError();
		}
		CloseHandle(hToken);
	}

	return result;
}

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

А компилить можно так же на 6 студии, чтоб без зависимостей:) но отключить совместимость с вин98 (выравнивание секций в файле по 4 кило).

MVV писал(а):Ну не так и муторно повысить привилегии.

Я говорил не про это, а про повышение уровня UAC. Запросить привилегию — это раз плюнуть, но система же не выдаст её обычному, неповышенному процессу. А главная сложность в том, что текущий процесс повысить нельзя, надо запускать новый и как-то обеспечивать взаимодействие повышенного с неповышенным.

Смотри, что получается: запросить привилегию сразу же после нажатия кнопки OK я не могу, потому что для жёстких ссылок и junction'ов она не требуется (а каждый раз выдавать UAC-окно, независимо от того, реально ли нужно повышение, — это не комильфо). Таким образом, я должен сделать это, только если пользователь захотел создавать именно симлинки. А определить эту ситуацию я смогу лишь на этапе окончательного разбора заданных пользователем параметров и обработки выделенных объектов, фактически, где-то посреди самого́ процесса создания ссылок (потому что даже если пользователь сказал делать, скажем, каталожные симлинки, далеко не факт, что у него вообще выбран хоть один каталог или что заданная глубина рекурсии не превысит реальную глубину выделенных каталогов). К этому моменту внутри программы накоплена дикая туча всевозможных внутренних структур (включая программный стек рекурсивной функции обхода каталогов), и чтобы обеспечить корректную работу, мне необходимо будет все их каким-то образом сериализовать и перебросить в повышенную копию. По сути, изобрести способ клонирования и восстановления внутреннего состояния программы. Я не говорю, что это абсолютно нерешабельно, но по-моему, эта задача по сложности на порядки превышает сложность всей NTFS Links как таковой.

Гораздо логичнее реализовать что-то типа Тоталовского tcmadmin, который будет работать повышенным и выполнять лишь собственно создание ссылок, а вся обработка, построение дерева и прочая мишура останется на совести основного процесса, который будет кидать повышенному лишь единичные команды по созданию конкретной ссылки. Но тут возникает другая проблема: если исходный каталог требует повышенных привилегий для чтения, то основной процесс NTFS Links его не прочитает. То есть, чтение тоже надо выносить в повышенного напарника. А раз так, то снова вылезает проблема своевременного запуска и передачи текущего состояния в обходе дерева каталогов из одного процесса в другой.

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

Добавлено спустя 3 минуты:

MVV писал(а):А компилить можно так же на 6 студии, чтоб без зависимостей

На шестой студии я 64-битку не скомпилю.
Нет уж, с шестёрки я окончательно ухожу. Жаль, конечно, но обеспечивать совместимость проектов между ней и 2008 становится слишком обеременительным делом.

Думаю, можно предварительно построить список создаваемых папок и симлинков/точек соединения, далее запустить себя с повышением, если юзер запросил создание симлинков и привилегию включить не удаётся... При первом же спорном моменте можно запрашивать повышения. И потом просто по построенному списку создавать папки и точки переподключения. Также можно добавить опцию - запрашивать всегда/при необходимости/не запрашивать (при варианте "запрашивать всегда" можно не строить список, если повышения ещё нет, а сразу запускать с повышением).

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

MVV
Да, я уже думал о построении списка. Это решает проблему, но создаёт другую: потенциально нехилое потребление памяти. Если обход идёт в потоковом режиме, то программа может обрабатывать произвольное число объектов без существенного увеличения требуемой памяти (потребление пропорционально всего лишь максимальному уровню рекурсии). Если же заранее создавать список, то занимаемая память становится пропорциональной числу объектов.

Можно прикинуть. Например, у меня сейчас в XP в папке Windows 50 тысяч файлов. Суммарное число символов в путях: 3,3 млн, т.е. 6,6 Мб. Плюс для каждого объекта надо хранить ещё целевой путь, т.е. примерно вдвое больше — 13 Мб. Плюс накладные расходы аллокатора… В общем, мегабайт 20 на одних только путях, а есть ещё и другие данные. Ну а в виртуальной Семёрке файлов уже 113 тысяч, и пути подлиннее, суммарная длина 14,5 млн символов. Соответственно, выходит уже памяти на ~90 Мб. А уж если кто-то, не дай Бог, решит Program Files склонировать на хорошенько обустроенной системе…

Возможно, всё-таки получится сделать потоковый вариант, в котором при любой ошибке доступа прога будет обращаться за тем же действием к повышенному помощнику. Конечно, ещё вопрос производительности встанет, т.к. я пока ещё слабо представляю, с какой скоростью данные перегоняются через пайп… В общем, думаю, прикидываю, соображаю.

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

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

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

При попытке скачивания, выдает вот такую картинку

Not Found

The requested URL /files/wdx_nl_info_1.20.rar was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

Apache/1.3.37 Server at flint.wincmd.ru Port 80

Можно выложить еще раз?

alk_banka
Прошу прощения, ошибся со ссылкой при обновлении инфы. Поправил, теперь качается.

CaptainFlint
Спасибки за обновление очередного, очень удобного плагина. Теперь совсем ТС будет универсален, с флешки (если я правильно понял) в 64 разрядной винде будут подгружаться 64 битные плагины. Даже в ТС 32-бит (Хоть есть и 64-битная версия отдельно). Поправьте, если не правильно понял.

alk_banka
Неправильно понял. 64-битные плагины принципиально невозможно загрузить в 32-битный Тотал, равно как и наоборот. Иначе Гислер не обещал бы такую приличную сумму за портирование плагинов на новую архитектуру.

Решил всё-таки выложить пока обновлённую версию с юникодом, но без поддержки вистовских ссылок. Что-то туго они у меня идут, слишком много вариантов поведения сразу появляется…

Версия 1.30

Программа теперь полностью юникодная.
Добавлена 64-битная версия.
Добавлена опция блокировки окна TC (эмуляция стандартных диалогов копирования/перемещения).
Путь к файлу настроек (ключ /i=<файл>) теперь поддерживает переменные окружения.
Основным языком сделан английский.
Разные незначительные улучшения.
Удалён файл описания интерфейсных строк.

Ссылки:
32-битная версия, зеркало (335 Кб)
64-битная версия, зеркало (353 Кб)

Из описания на сайте:

Некоторые программы, в частности - Проводник Windows, не умеют корректно распознавать символические ссылки! В результате при попытке удаления символической ссылки Проводником будет удалено всё содержимое оригинального каталога!

Не актуально, начиная с висты.

P.S. В русской справке, правда есть примечание (до XP, включительно). В английской лучше - (Windows Explorer in pre-Vista systems).

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

KhodeN писал(а):В английской лучше - (Windows Explorer in pre-Vista systems).

Не смог подобрать адекватную альтернативу на русском. Пре-Вистовые? До-Вистовые? До Висты? Последнее можно, но могут подумать, что включительно, придётся пояснять, в результате и получим либо "до XP включительно", либо "до Висты, не включая оную". Что в лоб, что по лбу…

CaptainFlint
В системах, предшествующих Windows Vista.

Total Commander

NTFS Links - обсуждение