¿Existe un sistema de archivos superpuesto FUSE que:
* resuelva por sí mismo "nombres de archivo demasiado largos" para el sistema de archivos subyacente
* de lo contrario (para nombres de archivo que se ajusten a los límites del sistema de archivos subyacente) solo proxy 1:1
?
Ejemplo de cómo podría funcionar esto:
para cada archivo fabc...yxz tener un nombre de archivo demasiado largo para el sistema de archivos subyacente dado, traducirlo a un nombre más corto y usar el segundo archivo como metadatos con los detalles completos del nombre de archivo.
Caso de uso:
Limitación de sistemas de archivos cifrados como EncFS o ecryptfs. Brindan la capacidad de almacenar nombres de archivo más cortos que en el sistema de archivos subyacente, al cifrar nombres de archivo, lo que resulta en que no puede sincronizar en ellos contenidos que requieren nombres de archivo más largos. (por ejemplo, Ext4 tiene 255B, ecryptfs en ext4 permite 143B de nombres de archivo).
Problemas de ejemplo rsync informes:
rsync: mkstemp "/mnt/naswaw2016/ext4/asusm2n1934/enc/home/gwpl/dane/cs/reed-solomon/.CS-05-569 - reed-solomon [vg][vgvg] - Optimizing Cauchy Reed-Solomon Codes for Faul
t-Tolerant Storage Applications - by James S. Plank.pdf.CwyPQH" failed: File name too long (36)
Algunas referencias:
- la misma idea propuesta anteriormente:https://github.com/vgough/encfs/issues/7#issuecomment-160678136
- Error de ecryptfs que describe el problema:https://bugs.launchpad.net/ecryptfs/+bug/344878
- SE responde sobre los límites de nombre de archivo de ecryptfs:https://unix.stackexchange.com/a/32834/9689
- error de escryptfs con caso de uso de rsync:https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/592303
(P.D. Y sí, soy consciente del cifrado en la capa de bloque con LUKS, pero el cifrado por encima de la capa fs es mucho mejor para mi caso de uso, prefiero apegarme a él)