windows symlinks - требуют повышенных привелегий

[ghost]

https://superuser.com/questions/124679/how-do-i-create-a-link-in-windows-7-home-premium-as-a-regular-user

компания microsoft конечно молодцы - право создавать символичесские ссылки есть только у админа, даже если это пользовательский каталог

[ghost]

вариант один - под windows не использовать mklink, менять пользовательский OSCRIPT_BIN и заставлять текущую консоль перечитывать переменные окружения

[ghost]

варинт 2 http://dbondarchuk.com/2016/09/23/adding-permission-for-creating-symlink-using-powershell/

под запускаемым пользователем запросить разрешение на создание симлинков

[ghost]

финальное исследование

на старых версиях windows - подстановка PATH=%OVM_OSCRIPTBIN% не происходит, требуется явное перименование. Так что наиболее выгрышный вариант - просто менять path на лету

[ghost]

товарищи из похожего проекта - переопределяем PATH играясь с временными переменными

https://github.com/shyiko/jabba/blob/master/command/use.go#L23

[nixel2007]

Как ты будешь менять PATH родительского процесса из дочернего?

[ghost]

@nixel2007 - ты меня тролишь что-ли ? переменные среды не ссылаются, а копируются в процесс при старте. Но это не означает что нельзя реализовать работу в пользовательском режиме хотя бы с этим допущением.

у нас 2 вопроса

• использовать ли под Виндой симлинки
• если не использовать, а использовать игры с переменными - как заставить текущие открытые процессы пользователя перечитать измененные пользовательские переменные

Я пока работаю над первым. Что касается второго - из документации Microsoft

Переменные для компьютера и пользователя копируется в блок среды текущего процесса.

Основная фишка что они копируются, а не ссылаются. Причем если использовалась подставновка %env%=%envslave%-some - она разыменовывается.

Текущий процесс засставить перечитать обновленные переменные окружения легко - примеры есть у choco и jabba проектов

А вот дочерние процессы формально никак, но у FAR есть интересная фишка - перечитывать переменные окружения, но тогда это уже доработка oscript - он может перечитывать oscript_bin и сверять что это он, если нет, то выдавать предупреждение и перезапускать (что выглядит как костыль, да и @EvilBeaver врядли такой костыль примет в виде пул-реквеста).

На текущий момент - чтобы обеспечить установку в среду пользователя достаточно будет сделать 3 вещи

• ovm use
• refreshenv
• send message "для применения обновленной версии oscript в дочерних процессах пожалуйста перезапустите их или вызовите команду ovm refreshenv"

в таком случае например на джобе jenkins нужно просто будет вызывать постоянно

ovm refreshenv
oscript

тогда если пользователь обновил oscript в соседнем процессе - то все будет корректно использовано.

Альтернативой этому лежит изменение групповой политики и выдача пользователю права создавать симлинки... но у windows с этим беда.

[nixel2007]

Ни в коем разе. Я просто тоже на это убил порядком времени. А что если переехать с мклинк на что-нибудь другое? Например на создание ярлыка или на junction?

[ghost]

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

но я это исследование добью. Обновил ноутбук - и опять вручную ставить oscript.

[ghost]

Продолжаю... Вот это поворот.

https://github.com/eagerestwolf/rvm-windows/blob/master/src/Installations.cs#L14

Интересно а использование kernel32 тоже требует повышенных привилегий

UPDATE:

судя по коду - как раз нет.

/// <summary>
        /// Check to see if the current user is running under an admin token or a restricted token.
        /// </summary>
        /// <returns>true if user is under admin token, false otherwise</returns>
        private static bool IsAdministrator()
        {
            WindowsIdentity identity = WindowsIdentity.GetCurrent();
            WindowsPrincipal principal = new WindowsPrincipal(identity);
            return principal.IsInRole(WindowsBuiltInRole.Administrator);
}

[ghost]

Оказывается рубисты молодцы, судя по всему код отсюда

https://stackoverflow.com/questions/11156754/what-the-c-sharp-equivalent-of-mklink-j
https://www.codeproject.com/Articles/15633/Manipulating-NTFS-Junction-Points-in-NET

Это мы так на доработку oscript.exe попадем.

Создал вопрос, нужна помощь зала - EvilBeaver/OneScript#800

[nixel2007]

А мы с netstandart не вылетим такими темпами?

[EvilBeaver]

Джункшены это объекты ядра и NTFS. Кажется, что как ни крути, а безопасность ОС обойти не удастся. Хоть на каком языке.

[EvilBeaver]

опасения с вылетом из netstandard не страшны, это можно оформить в виде внешнй компоненты

[nixel2007]

Попробуйте сейчас. на моей машине первый use прошел без требования админских прав.

[ghost]

@nixel2007 отработало на тестовой vagrant машине c обычным пользователем без права администрирования без ошибок

[ghost]

на старых версиях windows - подстановка PATH=%OVM_OSCRIPTBIN% не происходит

[nixel2007]

На какой конкретно? Вообще установкой переменных среды занимается дотнет, там вроде нечему работать по-разному на старых версиях винды. Есть вероятность, что на старых версиях может не отработать migrate, который переопределяет путь через реестр и домашний каталог powershell, но use должен работать.

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