Ошибка доступа к файлу 'C:Program Files1cv8conflogcfg.xml' #778629

В 64-битной ОС Windows 10 с выключенным контролем учетных записей (UAC) из 32-битного клиентского приложения, запущенного интерактивно без элевации (не через команду "Запуск от имени администратора"), выполняю попытку записать файл "C:Program Files1cv8conflogcfg.xml" и получаю исключение Ошибка доступа к файлу 'C:Program Files1cv8conflogcfg.xml' Моя учетная запись естественно входи в группу Администраторы. Как грамотно (с учетом идеологии контроля учетных записей) записать такой файл? Если даю доступ учетным записям "Все приложения" или "Все ограниченные приложения", то ошибка остается. Если даю доступ всем (учетная запись "Все") на этот файл, то ошибка уходит. Можно ли как то временно запросить у пользователя элевацию на конкретную файловую операцию? Как из кода 1С запустить приложение с элевацией?

Первое, что приходит в голову выполнить bat/shell скрипт. А пользователь пароль админа знает или нет?

"с выключенным контролем учетных записей (UAC)" // Его нельзя выключить. Наверное, имеется в виду самое "нижнее" положение ползунка в настройке уровней УАС?

>>Как грамотно (с учетом идеологии контроля учетных записей) записать такой файл? не отключать UAC не писать в системные директории.

так а если файл настроек системного журнала должен лежать именно в этом каталоге? По вашей теории нельзя автоматизировать этот процесс.

Файл настроек системного журнала? А какое отношение 1с может иметь к системному журналу?

технологического журнала имелось в виду

Технологический журнал, это журнал приложения. А приложение не должно хранить свои журналы, логи и прочие временные файлы в системных директориях. Т.е журналов там не должно быть. В речь идет про файл logcfg.xml - это файл настройки приложения. Он записывается при установке программы. И соответственно должен изменяться, перезаписываться, или удалятья только при установке или удалении данной программы.

Т.е есть базовый принцип - приложение не должно писать в Program Files, и уж тем более не должно там ничего хранить.

Я не разделяю ваше мнение, что файл настроек технологического журнала должен записыватсья при установке/удалении 1с. Это не временный файл, это не лог - это конфигурационный файл приложения (1с) для настройки логирования. Где ему еще лежать? Как минимум я знаю 2 случая, когда этот файл меняетя из 1с. В ЦУП и обработке настройки тех журнала.

Поясню - Если файл изменяется при работе программы, то его нельзя размещать в Program Files. Там можно размещать только файлы изменяемые при установке программы!

я даже затрудняюсь представить где должны лежать конфиги приложения (конфиги для того и есть, что бы их менять по потребности). 1. Конфиг это скорее постоянный файл чем временный. Часто без конфига приложение просто не будет запускатсья, а удаление временных файлов не должно влиять на работоспособность приложения. 2. Разработчики 1с решили, что конфиги должны лежать в папке c установленной платформой. 3. Довольно много программ хранят конфиги в <home directory>/conf , я сейчас много работаю с apache hadoop стеком и там все конфиги лежат именно в этом каталоге.

Все конфиги должны лежать в HomeDir. Это основа. В линуксе немного по другому, но принцип тот же.

Так, а что для платформы является home dir? Разве не папка куда установленая программа?

И самый ключевой момент в том, что разработчки платформы ожидают файл именно в том месте и пользователю остаеться только подстраиваться под ситуацию.

Пользователь знает пароль, но не хочет его вводить. Да.

HomeDir - домашняя директория пользователя, от имени которого запущена программа.

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

прав не хватает пользователю, под которым сервер запущен, поди

Где написано про сервер?

До меня вам точно не удалось донести суть. В папке пользователя лежат настройки относящиеся к конерктному пользователю, в папке с утановленной программой конфиги относящиеся к программе в целом.

Что нехватает прав это понятно. Не хватает прав пользователю, под которым записана программа. Почему не хватает - потому что пользователям нельзя писать в эту директорию.

считай, что у меня телепатический припадок.

По идеологии Windows в Programm Files хранится сама программа и необходнимые для нее библиотеки и данные. Они записываются в момент инсталляции, и используются только на чтение. В нее запрещено писать пользовательским программам.

Т,е хранить в Programm Files можно что угодно, а менять нельзя.

Спасибо. Хоть что то по существу вопроса =) Видимо придется использовать старый добрый hstart, который теперь поддерживает элевацию.

можно ссылку с описанием данной идеалогии? подойдет и на английском.

можно тупо прав накинуть на этот самый сам по себе logcfg.xml еще можно "mklink -j" и заныкать куда-то этот logcfg.xml, куда права есть. или в 1cv88..*inconfconf.cfg прописать ConfLocation, опять же туда, где есть права

Еще бы найти полностью бесплатную утилиту для выполнения команд системы с элевацией.

Того что запись в эту папку запрещена вам недостаточно?

wmic process create google that

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

Где тут про элевацию?

чем не устроил вариант из ?

Вот именно - вносить изменения туда может только админ, и система. Но никак не пользователь. А программа запускается от пользователя.

Научи запускать из 1С скрипт PowerShell и ловить выходной поток (сообщения).

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

в коментах так же приводили пример через bat

Опять через runas. Он всегда просит вводить пароль.

Решение найдено. elevate - Command-Line UAC Elevation Utility This utility executes a command with UAC privilege elevation. This is useful for working inside command prompts or with batch files.

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