No olvides que en las ciencias informáticas un problema casi siempere suele tener diversas resoluciones, no obstante enseñamos lo mejor y más óptimo.
Solución:
Consulte http://cjwdev.wordpress.com/2011/06/28/permissions-not-included-in-net-accessrule-filesystemrights-enum/
De esa página:
Al usar .NET, puede pensar que determinar qué permisos se asignan a un directorio/archivo debería ser bastante fácil, ya que hay una enumeración de FileSystemRights definida que parece contener todos los permisos posibles que puede tener un archivo/directorio y llamar a AccessRule.FileSystemRights devuelve un combinación de estos valores. Sin embargo, pronto se encontrará con algunos permisos en los que el valor de esta propiedad no coincide con ninguno de los valores de FileSystemRights Enum (me gustaría que no nombraran algunas propiedades con el mismo nombre que un tipo, pero bueno).
El resultado final de esto es que para algunos archivos/directorios simplemente no puede determinar qué permisos se les asignan. Si hace AccessRule.FileSystemRights.ToString, entonces para estos valores todo lo que ve es un número en lugar de una descripción (por ejemplo, Modificar, Eliminar, Control total, etc.). Los números comunes que puede ver son:
-1610612736, –536805376 y 268435456
Para determinar cuáles son realmente estos permisos, debe observar qué bits se configuran cuando trata ese número como 32 bits separados en lugar de como un número entero (ya que los números enteros tienen 32 bits) y compárelos con este diagrama: http: //msdn.microsoft.com/en-us/library/aa374896(v=vs.85).aspx
Entonces, por ejemplo, -1610612736 tiene el primer bit y el tercer bit establecidos, lo que significa que es GENERIC_READ combinado con GENERIC_EXECUTE. Entonces, ahora puede convertir estos permisos genéricos en los permisos específicos del sistema de archivos a los que corresponden.
Puede ver a qué permisos se asigna cada permiso genérico aquí: http://msdn.microsoft.com/en-us/library/aa364399.aspx. Solo tenga en cuenta que STANDARD_RIGHTS_READ, STANDARD_RIGHTS_EXECUTE y STANDARD_RIGHTS_WRITE son todos lo mismo (no tengo idea de por qué, me parece extraño) y en realidad todos son iguales al valor de FileSystemRights.ReadPermissions.
de https://social.technet.microsoft.com/Forums/windowsserver/en-US/5211a077-63fc-4016-b750-25bf26b3ad15/why-does-geacl-return-filesystemrights-that-are-invalid-in-filesystemaccesrule -usado-con-setacl?forum=winserverpowershell
268435456 – Control total
-536805376 – Modificar, Sincronizar
-1610612736 – Leer y ejecutar, sincronizar
(para ahorrarte algo de matemáticas)
En algunos casos, FileSystemRights tiene bits establecidos que no contienen información significativa y pueden eliminarse. Algunos tienen un formato que no es compatible con la clase FileSystemRights pero que se puede convertir. (El controlador NTFS admite ambos formatos). Hay varios documentos en Microsoft con respecto a esto:
- Formato de máscara de acceso
- Seguridad de archivos y derechos de acceso
- Winnt.h
En base a esto el método FileSystemRightsCorrector() limpia estos datos para que sean “legibles”. Hay un padre bool removeSynchronizePermission = false que debe usarse con el valor predeterminado, excepto que también tiene la necesidad de eliminar esta bandera.
public static FileSystemRights FileSystemRightsCorrector(FileSystemRights fsRights, bool removeSynchronizePermission = false)
C_BitGenericWrite
Si te ha resultado de utilidad este post, sería de mucha ayuda si lo compartes con otros programadores de esta forma nos ayudas a extender nuestra información.