2012-04-22 11 views
5

У меня есть приложение, которому необходимо создать каталог настроек в каталоге пользователя% APPDATA%. Для этого он использует код, подобный следующему:Приложение не может записываться в% APPDATA% (но пользователь может)

std::string appDataBase = getenv("APPDATA"); 
std::string appDir = appDataBase + "\\MyDir"; 

std::cerr << "About to invoke _mkdir(" << appDir << ")" << std::endl; 
int rv = _mkdir(appDir.c_str()); 
std::cerr << "_mkdir returned " << rv << ", errno = " << errno << std::endl; 

Однако при выполнении этого кода, то _mkdir вызов неудачен и errno устанавливается в EACCES:

About to invoke _mkdir(C:\Users\mdm\AppData\Roaming\MyDir) 
_mkdir returned -1, errno = 13 

Я предположил бы, что это простые разрешения, за исключением того факта, что (1) я могу создать каталог вручную в Проводнике без каких-либо проблем с разрешением, и (2) тот же самый код отлично работает, если я сам его скопирую в проект.

Я проделал обширный поиск информации об этой проблеме, но может найти ответы на общие проблемы с разрешениями, такие как пользователь, который не может получить доступ к этой папке с помощью проводника. Код в моем приложении работает, если я запускаю его как Администратор, поэтому ясно, что с его разрешениями происходит что-то странное, но я не знаю, что еще проверить. Я ознакомился с Process Explorer и подтвердил, что приложение работает с моей учетной записью пользователя, которая имеет полные права записи в каталоге% APPDATA%, и я убедился, что дерево% APPDATA% не установлено в «Скрытый» или «Только для чтения».

Есть ли какой-либо «эффективный идентификатор пользователя» или «эффективные разрешения», который может быть установлен в приложении Windows, что может зависеть от чего-то в конфигурации сборки или инициализации процесса? Существуют ли другие факторы, которые помешали бы одному конкретному приложению писать в% APPDATA%, в то время как другие пользовательские процессы могут?

Update

Дальнейшее исследование показывает, что разница в поведении не связана с содержанием коды, но расположения исполняемого файла в файловой системе. Мое приложение создается из исходного дерева внутри папки Development в моем каталоге пользователя, а вызов _mkdir не выполняется для исполняемых файлов в этом каталоге; однако, копирование файла .exe в новый каталог C:\Development позволяет ему работать нормально (хотя перемещение существующего каталога Development не выполняется). Простая тестовая программа находилась внутри Documents\Visual Studio\Projects, что также кажется удовлетворительным местом.

+0

«тот же самый код отлично работает, если я сам копирую его в проект» - тогда вы, вероятно, занимаетесь чем-то интересным в окружающем коде. Не могу догадаться, что. – Mat

+0

@Mat: это тоже мое предположение - к сожалению, у меня мало опыта в Windows, поэтому я не уверен, что искать в окружающем коде. –

+0

В качестве меры отладки попробуйте использовать Process Monitor (найдите веб-сайт MS), чтобы дважды проверить, какой путь пытается создать система, и какой код ошибки возвращается файловой системой. Может произойти какая-то переадресация, хотя я не понимаю, почему это было бы здесь. –

ответ

0

У Windows есть другой (и большой) набор функций для изменения контекстов безопасности. См. here для некоторых.

Возможно, проект, содержащий этот код, меняет контексты безопасности? Например, если программа запущена как сервер общего доступа, я бы предположил, что она вызовет, например, ImpersonateAnonymousToken().

 Смежные вопросы

  • Нет связанных вопросов^_^