Tengo una configuración de arranque dual compuesta por Windows 7 y Windows 10. Ambos están configurados en un disco C: como sistema y D: como disco de datos, que incluye el directorio de Usuarios. Y también tengo otro disco (¡físico también!), llamémoslo V:, con fotos y otras cosas.
En Windows 7, para acceder a las fotos desde el disco D: hice un enlace simbólico (unión) como este (razones históricas):
mklink /j d:\photos v:\photos
Y puedo acceder completamente a todas las carpetas en d:\photos. Intenté hacer lo mismo en Windows 10, pero no funciona correctamente como desearía. Puedo ingresar a d:\photos, pero no se puede acceder a ningún otro subdirectorio ni puedo escribir nada dentro de d:\photos. Pero puedo acceder a v:\photos sin problemas...
Si hago clic con el Explorador de Windows activado, por ejemplo. d:\photos\folder1, aparece "El sistema no puede mover el archivo a una unidad diferente". Si reviso la pestaña de seguridad en esa carpeta, encuentro el mensaje "La información de seguridad solicitada no está disponible o no se puede mostrar".
Ya intenté algunas cosas, pero sin éxito. ¿Puede ser el problema de que C: y D: estén en el mismo SSD y V: sea otro HD? ¿Alguna idea de qué hacer?
¡Gracias!
Respuesta1
Si bien se admiten uniones entre unidades locales, probablemente tendrá más suerte con los enlaces simbólicos del directorio real. Win7 (todo desde Vista, más específicamente) los admite, aunque XP y versiones anteriores no. Los enlaces simbólicos almacenan nombres de destino reales (por lo tanto, siempre que la otra unidad esté V:en ambos sistemas operativos, debería funcionar). Mi mejoradivinares que las uniones pueden usar un identificador distinto de la letra de unidad y cuando cambia de sistema operativo, el otro sistema operativo no comprende algunos de esos datos de identificación. Obviamente no lo hacenjustouse el nombre, o podría hacer una unión con una unidad de red asignada, y no podrá.
La sintaxis para crear un enlace simbólico verdadero para un directorio es la misma que para crear una unión, excepto que se utiliza la /Dmarca for mklink, en lugar de /J. Tenga en cuenta que, de forma predeterminada, sólo los administradores pueden crear enlaces simbólicos (no estoy seguro de por qué esto se aplica a los enlaces simbólicos y no a las uniones, pero c'est la vie). Entonces, inicie el símbolo del sistema como administrador (y sí, debe serlo CMD; mklinkes un CMD integrado, no su propio ejecutable al que podría llamarse, digamos, Powershell) e intente mklink /d d:\photos v:\photos.
Tenga en cuenta que también puede utilizar mklinksin banderas para creararchivoenlaces simbólicos, o con la /Hbandera para crear un archivoenlaces duros. No es relevante aquí, ya que estás intentando vincular directorios en lugar de archivos, pero es información potencialmente útil para el futuro. La mayoría de las personas no son conscientes de que NTFS admite enlaces físicos (desde... Windows 2000, ¿creo?) y enlaces simbólicos (desde Vista), incluso si conocen las uniones (que no son un enlace simbólico completo, o se podrían crear uno a una unidad de red).
Respuesta2
Tuve el mismo problema; Esto parece deberse al cambio de la ubicación de instalación de las aplicaciones a otra unidad.
Lo que me solucionó fue volver a configurar la ubicación para guardar las nuevas aplicaciones en C, y luego reiniciar en el símbolo del sistema (mantener presionada la tecla Mayús mientras reinicia) y eliminar "System Volume Information\wpappsettings.dat" en la unidad en cuestión.
Respuesta3
Tiene el mismo problema: tiene el disco C:(nuevo windows10) D:(antiguo) E:(antiguo)
Puedo crear uniones de directorio de D a C (para las subcarpetas "Archivos de programa", etc.), pero no puedo hacer lo mismo de E a D: se crearon uniones pero no puedo ver el contenido de los archivos ni las subcarpetas con el mismo error.
No entiendo por qué, pero todo se resolvió cargando Ubuntu y eliminando "D:\System Volume Information" (fue recreado por Win10 después).
PD. Tiene un resultado normal fsutil behavior query symlinkevaluation: local a* habilitado, remoto a* deshabilitado
Respuesta4
Me encontré con un problema similar hace un tiempo que fue causado por el sistema de permisos. En mi caso, tenía una ruta unc como destino, los permisos y el recurso compartido se habían configurado correctamente. En la ruta unc pude crear enlaces y sumergirme en subcarpetas, en la carpeta simbólica no. La razón había sido heredar los derechos de las carpetas superiores.
Intente deshabilitar los permisos de herencia para la carpeta simbólica y elimine los permisos que puedan causar problemas. Establezca permisos explícitos para obtener control total en la carpeta simbólica. En mi caso, resolvió los problemas y pude crear enlaces y sumergirme en las subcarpetas.