NTFS en Windows 7 (mover ficheros....)

Todos sabemos la teoría de la herencia de los ACLs de NTFS ¿Verdad?
La teoría se basa en tres reglas muy sencillas:

• Cuando un fichero (o directorio) se copia a un directorio nuevo heredará los permisos del nuevo directorio.
• Cuando un fichero (o directorio) se mueve de un directorio a otro de un disco (o unidad de red) diferente heredará los permisos del nuevo directorio.
• Cuando un fichero (o directorio) se mueve de un directorio a otro dentro del mismo disco (o unidad de red) mantendrá los permisos originales (por tanto no heredará los permisos del nuevo directorio).

¿Verdad que conocemos estas reglas?

Pues bien, las reglas del juego han cambiado desde Windows Vista / Server 2008. Ahora la tercera regla ha cambiado, y se escribe así:

• Cuando un fichero (o directorio) se mueve utilizando el explorador de Windows de un directorio a otro dentro del mismo disco y sus permisos se basan en la herencia de su directorio original (es decir, no tiene permisos específicos) heredará los permisos del nuevo directorio.

Aunque este cambio es claramente por diseño, para simplificar la herencia de permisos a partir de Windows 2008 Server, no he encontrado un artículo claro de Microsoft sobre el tema (en cuanto lo encuentre añado el link).

Sin embargo, si que hemos encontrado un artículo que indica que el comportamiento deseado no funcionaba siempre correctamente en Windows 7 y Windows Server 2008 R2 hasta que se aplica un parche:

http://support.microsoft.com/kb/2560088/en-us

Ctrl-Alt-Del (y otros) en sesiones RDP

Estaba yo tranquilamente conectado a una máquina por RDP (Windows 7 contra XP) y se me ha bloqueado la sesión del explorer. ¿Como hago que se ejecute el administrador de tareas? Necesito pulsar Ctrl-Alt-Del, pero si la pulso es la máquina local la que lo ejecuta.
He probado con Ctrl-Alt-Ins (en VMWare es así), pero tampoco. Tras algo de búsqueda he encontrado este [artículo] interesante.

Cambiar el programa que gestiona un tipo de ficheros desde la línea de comandos

A veces un programa no registra adecuadamente un tipo de ficheros. Por ejemplo, el .tif. ¿Cómo podemos cambiar desde la línea de comandos este programa? ¿Donde podemos verlo en el registro?

Un articulito muy interesante que me ha pasado Chu es el siguiente: http://commandwindows.com/assoc.htm, que describe cómo utilizar los comandos "assoc" y "ftype". Pero en mi caso no parece que funcionen por completo, así que hemos tenido que investigar un poco.

Conclusiones:

1. El comando "assoc" básicamente realiza cambios sobre HKCR (por lo tanto dentro de HKLM\Software\Classes) y se ha de ejecutar como administrador.
2. Los cambios que se realizan en HKCR luego pasan a la configuración del usuario (para algunos, como el cambio del icono, hay que cerrar sesión). Las claves interesantes del usuario están en HKCU\Software\Microsoft\Windows\Currentversion\Explorer\FileExts
3. Unas utilidades interesantes (aparte de regmon.exe de Sysinternals)http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx , las podemos encontrar en http://filext.com/faq/manage_file_extensions.php.

Otro enlace muy interesante relacionado con este tema:

http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/9898f3d7-a1f8-43fc-a958-8674b6e77595/

Adobe Preview Handler en Vista x64 (y Windows 7)

Al probar la edición de Windows 7 de 64 bits, me he encontrado un error "molesto" aunque no muy importante que ya me había ocurrido anteriormente con Vista.

Al recibir un PDF adjunto en un mail e intentar ver la vista preliminar de Outlook el sistema da un error que dice que el fichero no se puede previsualizar debido a un error del Adobe Preview Handler, y que hagas doble click sobre el fichero para abrirlo.

La solución pasa por añadir una clave al registro,

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID\{DC6EFB56-9CFA-464D-8880-44885D7DC193}]
"AppID"="{534A1E02-D58F-44f0-B58B-36CBED287C7C}"

He encontrado la solución más adecuada en: http://www.pretentiousname.com/adobe_pdf_x64_fix/index.html

Nombres de las carpetas en Windows Vista y compatibilidad con XP (Juntion Points)

¿Porqué si navegamos con el explorador de Windows Vista nos aparecen las carpetas “Archivos de Programa”, “Usuarios” y sin embargo si usamos la línea de comandos estas carpetas se llaman “Program Files” y “Users”? ¿Por qué ocurre lo mismo dentro de nuestro perfil con “Documentos”, “Imágenes”, etc.?

La solución parecía sencilla ya con XP, porque lo que hacen los señores de Microsoft es añadir un fichero oculto dentro de cada directorio denominado “desktop.ini” y lo utilizan para fijar el parámetro “LocalizedResourceName” adecuadamente.

Sin embargo con Vista van más allá, porque desde la línea de comandos yo puedo hacer “cd Program Files” y “cd Archivos de Programa” y termino en el mismo sitio, y además, la instalación de programas, que por defecto van a “Program Files” terminan con el programa en “Archivos de Programa”. ¿Qué está pasando?

Lo que han hecho con Windows Vista para evitar este problema es usar Juntion Points (es una característica de NTFS 5.0). Los Junction Points (JP en adelante) son enlaces que apuntan a otra parte del disco duro. Por ejemplo, los perfiles de usuario en Windows Vista se almacenan ahora en el directorio “c:\users”, pero existe un JP llamado “c:\documents and settings” para que los programas que buscan ese directorio vayan al sitio adecuado.

¿Cómo se visualizan los JP? Los JPs que creemos nosotros son visibles directamente con el explorador de Windows o desde la línea de comandos, pero a los que vienen con el sistema les han cambiado los atributos, de manera que el grupo “Todos” tiene el atributo “Read” denegado (de hecho, si intentamos abrir un JP desde el explorador nos da un error). Para verlos desde el explorador hay que pedir que nos muestre los archivos ocultos, y desde la línea de comandos se pueden ver con el comando “dir /aL”.

¿Cómo se crea un JP? Con la utilidad mklink “mklink /j vínculo destino”.

¿Cómo elimino los JP? Muy importante, si eliminamos un directorio que contiene un JP con algún comando recursivo, se borrará el contenido del destino del JP. Para borrar sólo el JP basta con usar el comando “rd”, como si de un directorio se tratara.

Por cierto, los JPs son antiguos (NTFS 5.0 está disponible con Windows 2000), y ahora con vista se han mejorado con los “Symbolic Link” (se crean también con mklink, pero con el parámetro /d), que mejoran por ejemplo el borrado recursivo (Vista se da cuenta y borra el enlace, pero no el original, y que pueden apuntar a un fichero).

Por cierto, la creación de JPs y Symbolic links requiere privilegios de administrador.

Enlaces Interesantes:

• http://msdn2.microsoft.com/en-us/library/ms906608.aspx
• http://www.svrops.com/svrops/articles/jpoints.htm
• http://www.digitalinsane.com/archives/2006/10/14/vista_profiles_folders

La madre de todas las impresoras (Core Drivers)

Otro de los problemas que me he encontrado, configurar mi impresora HP Deskjet 845c en Windows Vista. Además, parece que no soy el primero que se encuentra este problema (ver http://www.eggheadcafe.com/software/aspnet/29342928/missing-drivers.aspx).

El problema es que HP dice que no pone drivers a disposición del público porque los drivers están incluidos en Windows Vista (y es verdad, están en %systemroot%\system32\driverstore\filerepository\prnhp001.inf_5641fa75), pero al intentar instalar el driver que viene con Vista el sistema dice que no encuentra un "Core Program".

Tras varias investigaciones me he encontrado que con windows Vista un driver puede depender de otro que se llama "Core Driver" y que han cambiado algo la forma de empaquetar los drivers "Package aware drivers".

Tras mirar el fichero del driver de la impresora HP "prnhp001.Inf" he encontrado que el driver de esta impresora depende de dos "Core Drivers", el UNIDRV y el sRGBPROFILE.OEM. He encontrado que estos "Core Drivers" los instala el fichero de impresoras genérico de Microsoft "driverstore\filerepository\ntprint.inf_a6d3ccdf\ntprint.inf".

Mirando un poco dentro de estos dos ficheros me he encontrado los GUID de ambos "Core Drivers" {D20EA372-DD35-4950-9ED8-A6335AFE79F0} y ...F3}. Resulta que mirando un poquito en el registro me encontré que en la rama "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\PackageInstallation\Windows NT x86\CorePrinterDrivers" existía otra rama con la clave terminada en F0} (que es la del UNIDRV) y otra terminada en F5} (que es la del XPSDRV)pero no había una para la clave terminada en F3, así que con un par lo que he hecho para engañar a Windows es exportar la clave del registro de uno de estos GUIDS, cambiar el GUID para que terminara en F3 e importarla.

El fichero .reg es el siguiente:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\PackageInstallation\Windows NT x86\CorePrinterDrivers\{D20EA372-DD35-4950-9ED8-A6335AFE79F3}]
"InfPath"="C:\\Windows\\System32\\DriverStore\\FileRepository\\ntprint.inf_a6d3ccdf\\ntprint.inf"
"DriverDate"="06/21/2006""DriverVersion"="6.0.6000.16386"

Una vez aplicado el "parche", pido a Windows que reinstale el driver de la impresora y voila... Todo resuelto, no sólo eso, ahora en "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\PackageInstallation\Windows NT x86\CorePrinterDrivers" aparecen 5 entradas desde ...F0} hasta ...F5}.

Un par de enlaces interesantes son:

• http://msdn2.microsoft.com/en-us/library/aa907640.aspx
• http://www.microsoft.com/whdc/xps/pkginstall.mspx

Funcionamiento de los Drivers en Vista

Estoy teniendo un problema bastante gordo (creo que desde que intenté instalar un driver de un dongle bluetooth muy antiguo, pero no estoy muy seguro) que no me permite instalar nuevos dispositivos (ni siquiera un memory stick usb), pero antes de utilizar la opción del punto de restauración (es para cobardes) voy a investigar un poco.

Buscando buscando, he aprendido algunas cosas interesantes sobre los drivers en vista.

1. ¿Sabíais que en Windows Vista hay un directorio "%systemroot%\system32\driverstore" que contiene todos los drivers "confiables" que son los que Vista instalará de forma automática?
2. ¿Sabíais que si ponemos un driver ahí (por ejemplo el de una impresora), un usuario estándar podrá instalarlo de forma automática cuando conecte el dispositivo? Esto en XP no funcionaba.

Lo que he encontrado de momento es que mi Windows Vista no encontraba los drivers que estan en el "DriverStore", por lo que no podía instalar los drivers que vienen con Vista por defecto. Así que una solución temporal ha sido editar la entrada de registro "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\DevicePath" y le he puesto el valor "%SystemRoot%\inf; %SystemRoot%\system32\driverstore", cuando antes estaba sólo apuntando a "%systemroot%\inf".

Con este parche ahora windows encuentra los drivers siempre cuando le digo que busque en el PC, pero no lo hace de forma automática (con los memory stick solía ser así)... Seguiré investigando.

Dos documentos muy interesantes (especialmente orientados a Impresoras) son:

http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/PRI050_WH06.ppt

http://www.microsoft.com/whdc/xps/pkginstall.mspx

Recomendaciones para ejecutar el eMule en Windows Vista.

Uno de los primeros retos que me planteé con mi nuevo equipo (Windows Vista Ultimate preinstalado) fue la instalación del eMule.

Recorriendo varios foros, y con la inestimable ayuda de Google (G en adelante), encontré algunas de las recomendaciones a aplicar.

1. Debido al UAC de Windows Vista (tema que trataremos en otro post seguramente), es preferible instalar eMule en un directorio que se encuentre fuera de "C:\Program Files" (este es el verdadero nombre del directorio independientemente del idioma en Vista), por ejemplo en c:\emule.
2. En Windows Vista hay que modificar dos settings de eMule, que se encuentran en "Opciones Adicionales", se llaman "Máximas conexiones a medio abrir" y "Nuevas conexiones max./5s". En ambos casos se recomienda fijar el valor a 9.

http://www.emule-project.net/home/perl/news.cgi??l=1