Невозможно создать файлы в C:ProgramDataдаже после предоставления полного разрешения группе пользователей

Вопрос:У нас есть приложение, которое пытается записать в базу данных Access (.mdb) в папке C:ProgramData . На компьютерах с включенным UAC мы обнаруживаем, что доступ к базе данных терпит неудачу, поскольку кажется, что он не может создать файл блокировки. По-видимому, по умолчанию (и, возможно, из-за UAC) пользователи (включая администраторов) не имеют права на запись в

Вопрос:

У нас есть приложение, которое пытается записать в базу данных Access (.mdb) в папке C:ProgramData . На компьютерах с включенным UAC мы обнаруживаем, что доступ к базе данных терпит неудачу, поскольку кажется, что он не может создать файл блокировки. По-видимому, по умолчанию (и, возможно, из-за UAC) пользователи (включая администраторов) не имеют права на запись в папку приложений по умолчанию.

Мы думали, что предоставление полной прав доступа группы “Пользователи” к этой папке устранит проблему, однако это не имеет значения. Даже предоставление полного контроля “Все” по-прежнему не помогает. Единственное, что исправляет проблему, похоже, состоит в том, чтобы переместить базу данных в другую папку (например, C:applicationname), которая не является лучшей практикой или запускает приложение с правами администратора, изменяя ярлык.

Как мы можем сделать так, чтобы обычные пользователи могли писать (и создавать файлы) в папке C:ProgramData ? Или мы неправильно используем эту папку? У меня сложилось впечатление, что это правильное место для размещения общих данных программы (для всех пользователей), и многие другие приложения, похоже, размещают свои данные на моем компьютере.

Update:

Я обнаружил, что клонная копия базы данных была помещена в следующую папку:
C:Users\AppDataLocalVirtualStoreProgramData

Если я удалю эту папку, приложение будет работать нормально. Почему была создана эта папка? Могу ли я это предотвратить? Может быть, из-за того, что установщик не дает соответствующих прав для группы Users в папке в C:ProgramData ?

Лучший ответ:

Может ли это быть из-за того, что установщик не предоставляет соответствующие права для группы Users в папке в C:ProgramData ?

На самом деле, скорее всего, у установщика не было достаточных разрешений для беспорядка с “C:ProgramData”. (Я думал, что этот сценарий звучит знакомо….)

Когда Microsoft представила UAC, им потребовался способ, чтобы старые приложения продолжали работать, по крайней мере, на некоторое время. То, что они придумали, было “Виртуализация файлов и реестров”, где устаревшие приложения, которые пытались получить доступ (теперь -) verboten Системные папки или записи реестра, были перенаправлены на собственную “виртуализированную” копию этих ресурсов для каждого пользователя. Как гласит статья Википедии о UAC:

Приложения, написанные с предположением о том, что пользователь будет работать с правами администратора, испытывают проблемы в более ранних версиях Windows при запуске из ограниченных учетных записей пользователей, часто потому, что они пытались писать в машинные или системные каталоги (например, программные файлы) или ключей реестра (в частности, HKLM). [4] UAC пытается смягчить это с помощью виртуализации файлов и реестров, которая перенаправляет записи (и последующие чтения) на местоположение каждого пользователя в профиле пользователя. Например, если приложение пытается записать в такой каталог, как “C:Program Filesappnamesettings.ini”, к которому у пользователя нет разрешения на запись, запись будет перенаправлена ​​на “C:Usersusername” AppDataLocalVirtualStoreProgram Filesappnamesettings.ini “. Функция перенаправления предоставляется только для невыдвинутых 32-разрядных приложений и только в том случае, если они не содержат манифест, запрашивающий определенные привилегии. [13]

Если ваш установщик запрашивает привилегии “Запуск от имени администратора”, вы можете избежать этой проблемы.

Оцените статью
Добавить комментарий