Existe-t-il un système de fichiers superposé FUSE, qui :
* résout par lui-même les "noms de fichiers trop longs" pour le système de fichiers sous-jacent
* sinon (pour les noms de fichiers correspondant aux limites du système de fichiers sous-jacent) juste proxy 1:1
?
Exemple de fonctionnement :
pour chaque fichier fabc...yxz ayant un nom de fichier trop long pour le système de fichiers sous-jacent donné, traduisez-le en un nom plus court et utilisez le deuxième fichier comme métadonnées avec les détails complets du nom de fichier.
Cas d'utilisation :
Limitation des systèmes de fichiers chiffrés comme EncFS ou ecryptfs. Ils offrent la possibilité de stocker des noms de fichiers plus courts que dans le système de fichiers sous-jacent, lors du cryptage des noms de fichiers, ce qui vous empêche de synchroniser avec eux les contenus qui nécessitent des noms de fichiers plus longs. (par exemple, Ext4 a 255 B, ecryptfs sur ext4 autorise 143 B de noms de fichiers).
Exemples de problèmes rsync rapport :
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)
Quelques références :
- même idée proposée précédemment :https://github.com/vgough/encfs/issues/7#issuecomment-160678136
- Bug ecryptfs décrivant le problème :https://bugs.launchpad.net/ecryptfs/+bug/344878
- Réponse SE sur les limites de nom de fichier d'ecryptfs :https://unix.stackexchange.com/a/32834/9689
- Bogue escryptfs avec cas d'utilisation rsync :https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/592303
(P.S. Et oui - je suis conscient du chiffrement sur la couche de bloc avec LUKS, mais le chiffrement au-dessus de la couche fs est tellement mieux pour mon cas d'utilisation que je préfère m'y tenir)