.png)
A veces, cuando intento eliminar una carpeta en Windows, aparece un mensaje que indica que necesito permiso de [mi cuenta actual] para eliminar esa carpeta. Lo cual es extraño, porque ya inicié sesión como ese usuario. Sin embargo, cuando abro la carpeta, selecciono todos los contenidos y los elimino (sin ningún tipo de mensaje), puedo volver a subir y eliminar la carpeta original sin el mensaje de seguridad.
Esto sucede con mayor frecuencia en las carpetas de proyectos creadas por Visual Studio (a menudo, las carpetas .vs y .git causan este problema), pero también ha sucedido con otras carpetas. También sucede de forma recursiva: abro una carpeta problemática, elimino todo el contenido, recibo un mensaje que indica que no se pueden eliminar un montón de subcarpetas, abro cada subcarpeta, elimino todo el contenido, etc.
Si reviso la carpeta con Process Explorer, no puedo encontrar ningún proceso adjunto a la carpeta ni ninguno de sus contenidos.
Parece que esto sería fácil de automatizar, pero ¿por qué sucede esto en primer lugar?
Respuesta1
Muchas veces me he preguntado lo mismo. Los sistemas basados en Unix (Linux) no presentan este problema y supongo que hay un problema de kernel entrelazado que MS no está dispuesto a afrontar.
He investigado esto varias veces. Estoy tratando de ayudarte, pero de ninguna manera mi conocimiento es una respuesta definitiva. No recuerdo este problema hasta win7 y el hecho de que persista me hace creer que el problema es demasiado complicado y profundo en el kernel de MS como para querer solucionarlo.
La primera posibilidad es que otros procesos estén de alguna manera bloqueados o estancados. Podría ser tan simple como que el Explorador de archivos acceda pero no libere el programa cuando quiera el ícono del programa.
Otra posibilidad es que el programa de almacenamiento en caché de MS tenga algún problema desconocido o esté confuso, por lo que algún proceso o damen le haya dicho al administrador de archivos que está en uso, o que tal vez debería mantenerse disponible.
O la propiedad se arruina. Quizás después de acceder a él, la tabla de propiedades del archivo muestre que el sistema lo está usando o tiene control sobre él y ningún usuario tiene privilegios para hacerle algo. Esto puede estar asociado con un problema de bloqueo de archivos.
Mi mejor suposición, y es un tiro en la oscuridad, es que de alguna manera el archivo y el administrador de memoria se estropean y la información de los archivos deja de ser editable, incluso por el sistema o el kernel.
Una pista que apunta a un problema de caché/memoria/o administrador de archivos del kernel es que desaparece después de reiniciar (tal vez indicando un problema de propiedad o de bloqueo de archivos en uso). Cualquiera que sea el problema, es un error importante de Microsoft (y ellos son conscientes de ello) y sus mejores y más brillantes programadores no pueden resolverlo de manera rentable y eficaz en términos de recursos.