Cómo enlazar correctamente archivos simbólicos en ~/Library/Preferences

¿Cómo puedo simlink fiable archivos en el ~ / Biblioteca / Preferencias

No lo hagas.

Por lo general, estos archivos no son para consumo del usuario. Son los archivos de soporte de las aplicaciones que utilizas a diario. Algunos no son más que archivos de configuración, mientras que otros almacenan datos como (Firefox) sitios visitados recientemente, marcadores, etc.

Quiero versionar estos archivos en mi repo de dotfiles.

¿Por qué? A menos que seas un desarrollador, no hay razón para versionar estos archivos, especialmente porque algunos cambian no sólo a diario, sino a medida que usas la aplicación.

Esto también me permite cambiar el nombre del archivo a algo conveniente, incluso si el desarrollador original eligió un mal nombre para el archivo de configuración.

Una vez más, esto no está destinado al consumo general y adivinar el desarrollador y sus convenciones de nomenclatura puede causar problemas. Por ejemplo, muchas aplicaciones se actualizan simplemente descargando sólo los archivos modificados, mientras que otras descargan toda la aplicación y simplemente sobrescriben lo que había (Firefox es un buen ejemplo). En cualquier caso, se espera que los archivos de soporte estén donde el desarrollador dijo que estarían. También hay muchos casos en los que el archivo de configuración debe ser migrado ya que utiliza un formato diferente y las "herramientas" que implementa el desarrollador para realizar esta migración pueden no esperar un enlace simbólico.

Sin embargo, esto no parece funcionar de forma consistente en los Macs - a veces el propio enlace simbólico se sobrescribe, a veces establecer el enlace simbólico en "Bloqueado" lo soluciona y a veces no.

Un ejemplo.

Me gusta que mi repo de dotfiles esté en su propia carpeta ordenada

De acuerdo... puedo apreciar una jerarquía de archivos limpia y ordenada. Sin embargo, como las aplicaciones esperan que los archivos de la Biblioteca estén donde están originalmente, esa carpeta será la misma lista de enlaces simbólicos desorganizada y mal nombrada. Así que, básicamente, todo para nada.

Si alguien se lo pregunta, mi enfoque actual es el siguiente:

1. Modificar algunos ajustes en la aplicación, a continuación, hacer rápidamente find ~ -mtime -1m 2>/dev/null para ver los archivos modificados recientemente y encontrar el archivo donde la aplicación almacena las configuraciones. (algunas aplicaciones no escriben las configuraciones hasta que las abandonas).
2. Con la aplicación cerrada, mueva la configuración al repositorio dotfiles: mv ~/Library/Preferences/com.someapp.whatever.blah.blah.plist ~/dotfiles/someapp-config.dat
3. Enlace simbólico desde la ubicación original: ln -s ~/dotfiles/someapp-config.dat ~/Library/Preferences/com.someapp.whatever.blah.blah.plist
4. Bloquea el enlace simbólico para que la aplicación no pueda sobrescribirlo (debería poder cambiar el contenido del archivo): chflags nouchg ~/Library/Preferences/com.someapp.whatever.blah.blah.plist (es lo mismo que hacer clic con el botón derecho del ratón sobre el enlace simbólico en Finder, seleccionar "Obtener información..." y luego "Bloqueado")
5. Compromiso ~/dotfiles/someapp-config.dat a su repositorio. Por lo general, estos archivos son binarios y el diff no es demasiado útil, por lo que sugiero describir sus cambios de configuración en el mensaje de confirmación. Probablemente también quieras añadir los comandos symlink y lock a un shell script para facilitar la implementación en máquinas posteriores (idealmente sería tan fácil como git clone DOTFILE_URL; ~/dotfiles/install-symlinks.sh ).

Esto parece funcionar. Sin el paso de bloqueo, muchas aplicaciones borrarían el enlace simbólico y crearían un archivo de configuración nuevo. Pero cuando se bloquea, se ven obligadas a seguir el enlace simbólico y trabajar con el contenido del archivo versionado.

Tuve un caso en el que parecía que el enlace simbólico se sobrescribía a pesar de estar bloqueado, pero no estoy del todo seguro de si realmente lo bloqueé. Después de intentarlo de nuevo y asegurarme de bloquearlo, no pude reproducir el problema - así que tal vez accidentalmente no lo bloqueé la primera vez. Voy a editar el post si encuentro un caso reproducible de la Lock no es suficiente.

Alternativamente, es posible hacerlo sin bloqueo en absoluto (no probado, los comandos pueden tener errores menores):

1. Copiar todo el directorio de preferencias a dotfiles: cp -r ~/Library/Preferences ~/dotfiles/
2. Sustituye el original por un enlace simbólico: ln -s ~/dotfiles/Preferences ~/Library/Preferences
3. Probablemente no quieras versionar indiscriminadamente toda tu biblioteca de Preferencias, así que añádelo a .gitignore : Preferences/
4. Utilice el mismo truco recientemente modificado para encontrar el archivo o archivos de configuración pertinentes: find ~/dotfiles/Preferences/ -mtime -1m 2>/dev/null
5. El archivo no aparecerá en git status al principio porque se ignora, pero aún así puedes git add com.someapp.whatever.blah.blah.plist (los cambios en el archivo aparecerán en git status después de añadirlo una vez)

La ventaja de este enfoque es que no tiene que bloquear ningún archivo porque incluso si un programa borra y vuelve a crear el archivo de configuración, seguirá apareciendo en el directorio con enlaces simbólicos de su repositorio. La desventaja es que puedes acabar con un montón de archivos en tu repositorio local - con el uso ordinario de git y si los ignoras como he descrito antes, los archivos no serán confirmados o enviados a git, pero si alguna vez copias manualmente el repositorio (en oposición a git clone como debería ser) entonces tienes que tener en cuenta que lo estás copiando todo.

No creo que sea necesario bloquear el enlace simbólico ~/Library/Preferences porque ese directorio no debería sobrescribirse (al contrario que su contenidos ).