Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602  Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 396 раз в 366 постах
|
Цитата:if DEFINED ProgramFiles(x86) Всю жизнь считал что проверка существования файла/папки это EXIST или EXISTS и где пробелы Цитата: это batch-сценарий, но Я привык именовать как *.cmd от слова - "command". Я тоже с некоторых пор придерживаюсь такого именования, так как со времен windows xp (20 лет, Карл!) .bat было оставлено для DOS сценариев, а .cmd для новых сценариев. Неизвестно когда первое внезапно выпилят, но многие до сих пор упорно используют расширение .bat. Хотя сейчас уже видимо скоро выпилят оба - читали же о том, что утилиту wmic уже выпилили - якобы часто используют вирусы и рекомендовали перейти на PowerShell. Не то чтобы я сильно против PowerShell, но слишком много там сырого по сравнению с утилитами. Отредактировано пользователем 1 марта 2022 г. 10:58:25(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.05.2016(UTC)
Сообщений: 2,655
Сказал(а) «Спасибо»: 614 раз
Поблагодарили: 459 раз в 433 постах
|
Автор: two_oceans  Цитата:if DEFINED ProgramFiles(x86) Всю жизнь считал что проверка существования файла/папки это EXIST или EXISTS и где пробелы Оперируем переменной окружения. Проверяя с помощью "EXISTS" наличия директории может сложится такая ситуация, когда какое-то "левое" ПО эту директорию просто создало по ошибке (такое ПО иногда встречается).
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 396 раз в 366 постах
|
Автор: nickm когда какое-то "левое" ПО эту директорию просто создало по ошибке (такое ПО иногда встречается) ОК, но замечу, что переменные окружения могут создаваться для системы, пользователя, процесса и т.п. Процесс не считаем, так как вряд ли мы запускаем сценарий из под того левого ПО. Тем не менее, для создания переменной окружения пользователя даже не требуется прав администратора. UPDATE. Как оказалось, для создания папки в корне диска C: по нынешним временам права администратора НЕ нужны.Отредактировано пользователем 1 марта 2022 г. 11:34:57(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.05.2016(UTC)
Сообщений: 2,655
Сказал(а) «Спасибо»: 614 раз
Поблагодарили: 459 раз в 433 постах
|
Автор: two_oceans В то же время, для создания папки в корне диска C: по нынешним временам права администратора нужны. Проверьте на дефолтной системе под простым пользователем.
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 396 раз в 366 постах
|
Вы правы. группа Пользователи имеет право на создание папок (для этой папки и ее подпапок), создание файлов (только для подпапок) в корне системного диска. файл записать не вышло, а папку создать свободно. Зато у папки Windows порядок с правами (простому пользователю отказ в создании папки), можно там искать C:\Windows\SysWOW64 с той же целью. Отредактировано пользователем 1 марта 2022 г. 11:40:52(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.05.2016(UTC)
Сообщений: 2,655
Сказал(а) «Спасибо»: 614 раз
Поблагодарили: 459 раз в 433 постах
|
Автор: two_oceans Тем не менее, для создания переменной окружения пользователя даже не требуется прав администратора. Можно смело предполагать, что переменная окружения %ProgramFiles(x86)% всегда определена верно. Если данная переменная каким либо образом удалена/ повреждена/ не читается/ возвращает ошибку, тогда полагаю, систему можно считать "сломанной", т.к. уверен, что большое количество программного обеспечения оперирует данной системной переменной. Автор: two_oceans можно там искать C:\Windows\SysWOW64 с той же целью. Можно, но нужно ли?
|
|
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 396 раз в 366 постах
|
Автор: nickm Ссылка на миграцию профилей при развертывании операционки как-то не выглядит убедительной. Более того, похоже CSIDL_PROGRAM_FILESX86 или ProgramFiles(x86) это не переменная окружения системы или пользователя как таковая (если Вы откроете "Дополнительные параметры системы" - "Переменные среды" ее там нет), попытка создания ProgramFiles(x86) с левым значением успешна, но стоит переоткрыть и ее снова нет, хех. Консоль тоже не знает измененного значения. Тем не менее в консоли ее изменить и даже удалить возможно, но действует только в текущем окне консоли. Итак, вспомним, что CSIDL_* это индексы для SHGetFolderLocation (или новых функций SHGetKnownFolderPath) и большинство программ используют их именно через SHGetFolderLocation. Похоже переменная создается из SHGetFolderLocation при открытии консоли и действует только для процесса. В таком случае ее конечно сложно испортить, но это не значит, что совсем уж невозможно переопределить что возвратит SHGetFolderLocation. Правка реестра творит чудеса, хотя там без прав администратора будет сложновато.
Автор: nickm уверен, что большое количество программного обеспечения оперирует данной системной переменной. При установке - да, msi также определяет константы CSIDL_* как допустимые значения. Однако в обычной работе проще просто взять текущую папку или базовый путь из реестра, сохраненный при установке. Установщик Windows кстати методично хранит пути установки, даже если самой программе лениво сохранить. Цитата:Если данная переменная каким либо образом повреждена ошибку, тогда полагаю, систему можно считать "сломанной" С чего бы, от того что Вы переименуете папку система точно не сломается - все важное она хранит в Windows и в 64-разрядном виде, а отвал нескольких 32-разрядных приложений не так важен даже если это ИЕ.
Короче, в стабильности %ProgramFiles(x86)% Вы меня убедили (переопределить SHGetFolderLocation случайно не выйдет, согласен), но про важность данной переменной не в момент установки программ я очень сомневаюсь. Отредактировано пользователем 1 марта 2022 г. 12:57:04(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,128
Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 154 раз в 139 постах
|
Код:> set pr|findstr ARC
PROCESSOR_ARCHITECTURE=AMD64
?
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 31.05.2016(UTC)
Сообщений: 2,655
Сказал(а) «Спасибо»: 614 раз
Поблагодарили: 459 раз в 433 постах
|
Автор: basid Код:> set pr|findstr ARC
PROCESSOR_ARCHITECTURE=AMD64
? Зависит от архитектуры вызываемого приложения. Код:Microsoft Windows [Version 10.0.19044.1566]
(c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.
C:\Users\nickm>cd C:\Windows\SysWOW64\
C:\Windows\SysWOW64>cmd
Microsoft Windows [Version 10.0.19044.1566]
(c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.
C:\Windows\SysWOW64>set pr|findstr ARC
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_ARCHITEW6432=AMD64
C:\Windows\SysWOW64>
Отредактировано пользователем 1 марта 2022 г. 13:57:01(UTC)
| Причина: Не указана
|
|
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 21.11.2010(UTC)
Сообщений: 1,128
Сказал(а) «Спасибо»: 7 раз
Поблагодарили: 154 раз в 139 постах
|
Т.е. специально вызвать 32-разрядную версию cmd.exe чтобы что: Код:> set pr|findstr Program
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files (x86)
ProgramFiles(x86)=C:\Program Files (x86)
ProgramW6432=C:\Program Files
?
|
|
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close
