[TC] Досадный баг в моей сборке Total Commander
Доброго времени суток всем!
Исходя из того, что никто с этим багом не столкнулся, я могу сделать несколько
предположений:
* 99 пользователей из 100 используют TC в портабельном режиме;
* тот один пользователь, который напоролся на баг, исправил его сам. Искренне
надеюсь, что сделал он это не через Алису, или гигачат, свят-свят-свят, а,
пользуясь поиском, или, хотябы, спросив у вменяемых нейросетей.
Ниже я расскажу, что происходит и расскажу, как это исправить, если вы, как и
я, предпочитаете установочные программы портабельным.
Баг выражается в том, что если вы решили сделать тотал установочным и у вас
включен контроль учётных записей, вы не сможете сохранить настройки тотала.
Повезло тем, кто по советам "умных" онлайнпреподавателей отключил UAC, а так
же сторонникам портабельных программ. Всем остальным неумникам, которые
послушались вашего покорного слуги, а так же разработчиков Windows и UAC не
трогали немного не повезло, ибо мы с вами столкнулись с этим багом.
Пока пир сторонников лучших в мире онлайн-преподавателей не утихает, понурив
голову, давайте просто вместе исправим этот баг, а заодно и разберём его, ведь
не ошибается только тот, кто ничего не делает.
Сначала разберём работу установщика.
Это - обычный самораспаковывающийся архив Winrar, логика которого прописана в
архивном комментарии. Когда вы выбираете папку установки, модуль просто
распаковывает туда файлы и вот тут начинаются песни и пляски.
Если пользователь пишет в поле пути к папке нечто вроде c:\totalcmdportable,
всё будет хорошо, но по умолчанию модуль пытается распаковать себя в папку
Total Commander папки Programm Files, а папка эта огорожена заборами NTFS и
злыми немецкими овчарками в виде файловых разрешений.
Чтобы иметь возможность создать папку Total Commander модулю приходится
повышать права, т.к. по умолчанию никаких прав администратора он не получает.
Именно отсюда и запрос UAC при установке в папку по умолчанию, а так же его
отсутствие, если пользователь изменил имя папки на своё.
Теперь едем дальше: модуль отработал, распаковал файлы и передал управление
скрипту firststart.cmd, и вот тут я, реально, лох, потому что прозевал
очевидный момент: скрипт так же запустился с повышенными правами и у любого
объекта файловой системы, которые создаст скрипт, будут права не текущего
пользователя, а группы "Администраторы" со всеми вытекающими.
То есть, скрипт переместит конфиг тотала из его папки в папку
пользовательского профиля, а вот иметь возможность записывать в этот конфиг мы
не сможем. Придётся или запускать тотал от имени администратора, что, кстати
говоря, очень плохая идея, или же надо сделать следующее:
1. Стать владельцем папки ghisler, находящейся в папке данных программ вашего
пользовательского профиля, а так же владельцем всех вложенных её объектов,
после чего дать себе полный доступ к этой папке и всем вложенным объектам.
Откройте командную строку от имени администратора и последовательно выполните
две команды:
icacls "%appdata%\ghisler" /setowner "%USERDOMAIN%\%USERNAME%" /T /C
icacls "%appdata%\ghisler" /grant %USERNAME%:F /T
Первая команда сделает вас владельцем нужной папки, а вторая выдаст полный
доступ.
Тут въедливые читатели, которые не только ENTER могут нажимать, могут
возразить, мол, дорогой мой хороший, с тех пор, как появилась Windows NT для
того, чтобы сделать себя владельцем, используется команда takeown, а ты тут
городишь всякую ерунду... Они будут и правы, и неправы одновременно. Takeown
действительно может назначить владельца, но: она оперирует не именем
пользователя, а маркером доступа. Вплоть до Windows XP это никому не мешало,
потому, что у пользователя в рамках его сессии был всегда только один маркер
доступа. Начиная с Windows Vista этих маркеров стало два:
1. Обычный маркер безопасности, когда пользователь лайкает себе своих котегов;
2. Повышенные права доступа, фактически, администратор, хотя и не совсем,
когда выскочил UAC и пользователь подтвердил повышение прав.
Именно поэтому в скрипте, который запускает установщик, использование команды
takeown недопустимо, ибо оно приведёт к тому, что и так произошло: владельцем
папки и всех вложенных файлов будет группа администраторы.
По-скольку без велосипедов с квадратными колёсами понизить свои права в рамках
сессии консоли мы не можем, мы и не пользуемся takeown.
Есть и ещё один неприятный баг: невозможность сохранения настроек Akelpad в
установочном режиме из-за тех же самых ошибок прав доступа. Решение в точности
такое же, или просто удалить файл akelpad.ini, чтобы все настройки в
установочном режиме сохранялись в реестре. В своей сборке, кстати, так и
сделаю.
Приношу извинения за данный баг, надеюсь, его подробнейший разбор будет
небольшим подслащением пилюли для тех, кто с этим багом столкнулся.
