2012-04-22 11 views
5

Tengo una aplicación que necesita crear su directorio de configuración dentro del directorio% APPDATA% del usuario. Para ello se utiliza un código similar al siguiente:La aplicación no puede escribir en% APPDATA% (pero el usuario puede)

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; 

Sin embargo, cuando se ejecuta este código, la llamada _mkdir falla y errno se establece en EACCES:

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

Me hubiera asumido esta es una Permiso simple, excepto por el hecho de que (1) puedo crear el directorio manualmente en el Explorador sin ningún problema de permiso, y (2) el mismo código funciona bien si lo copio en un proyecto por sí mismo.

He realizado una extensa búsqueda de información sobre este tema, pero solo puedo encontrar discusiones sobre problemas de permisos generales, como que el usuario no pueda acceder o escribir en esta carpeta mediante el Explorador. El código en mi aplicación funciona si lo ejecuto como administrador, así que claramente está ocurriendo algo extraño con sus permisos, pero no sé qué más verificar. He inspeccionado con Process Explorer y he confirmado que la aplicación se está ejecutando con mi cuenta de usuario, que tiene permisos de escritura completos en el directorio% APPDATA%, y me he asegurado de que el% APPDATA% tree no esté configurado como Oculto o Solo lectura.

¿Existe algún tipo de "identificación de usuario efectiva" o "permisos efectivos" que se puedan establecer en una aplicación de Windows, lo que podría depender de algo en la configuración de compilación o la inicialización del proceso? ¿Existen otros factores que impidan que una aplicación específica escriba en% APPDATA% mientras que otros procesos de usuario pueden?

actualización

La posterior investigación revela que la diferencia de comportamiento no está relacionado con el contenido del código, pero el ubicación del ejecutable en el sistema de archivos. Mi aplicación se está construyendo desde un árbol fuente dentro de una carpeta Development en mi directorio de usuario, y la llamada _mkdir falla para ejecutables dentro de este directorio; sin embargo, copiar el archivo .exe en un nuevo directorio C:\Development le permite funcionar bien (aunque mover el directorio existente Development no). El programa de prueba simple estaba dentro de Documents\Visual Studio\Projects, que también parece ser una ubicación satisfactoria.

+0

"el mismo código funciona bien si lo copio en un proyecto por sí mismo" - entonces probablemente estés haciendo algo interesante en el código que lo rodea. Realmente no puedo adivinar qué. – Mat

+0

@Mat: esa sería mi suposición también. Desafortunadamente, tengo poca experiencia en el desarrollo de Windows, así que no estoy seguro de qué buscar en el código circundante. –

+0

Como medida de eliminación de errores, intente usar Process Monitor (busque en el sitio web de MS) para verificar qué camino está intentando crear el sistema y qué código de error está devolviendo el sistema de archivos. Puede haber algún tipo de redirección, aunque no entiendo por qué ese sería el caso aquí. –

Respuesta

0

Windows tiene un conjunto diferente (y grande) de funciones para cambiar los contextos de seguridad. Ver here para algunos.

¿Quizás el proyecto que contiene ese código está cambiando los contextos de seguridad? Si el programa se está ejecutando como un servidor de acceso público, esperaría que llamara al ImpersonateAnonymousToken(), por ejemplo.

Cuestiones relacionadas