C'è un filesystem in overlay FUSE, che:
* risolve da solo "nomi di file troppo lunghi" per il filesystem sottostante
* altrimenti (per i nomi di file che si adattano ai limiti del filesystem sottostante) solo proxy 1:1
?
Esempio di come potrebbe funzionare:
per ogni file fabc...yxz se il nome del file è troppo lungo per un determinato filesystem sottostante, traducilo in un nome più breve e usa il secondo file come metadati con i dettagli completi del nome del file.
Caso d'uso:
Limitazione di filesystem crittografati come EncFS o ecryptfs. Forniscono la capacità di memorizzare nomi di file più brevi rispetto al filesystem sottostante, quando si crittografano i nomi di file, risultando che non è possibile sincronizzare in essi contenuti che richiedono nomi di file più lunghi. (ad es. Ext4 ha 255B, ecryptfs su ext4 consente 143B di nomi di file).
Esempi di problemi rsync segnalazione:
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)
Alcuni riferimenti:
- stessa idea proposta in precedenza:https://github.com/vgough/encfs/issues/7#issuecomment-160678136
- bug di ecryptfs che descrive il problema:https://bugs.launchpad.net/ecryptfs/+bug/344878
- Risposta SE sui limiti dei nomi di file di ecryptfs:https://unix.stackexchange.com/a/32834/9689
- bug escryptfs con caso d'uso rsync:https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/592303
(P.S. E sì, sono consapevole della crittografia a livello di blocco con LUKS, ma la crittografia sopra il livello fs è molto meglio per il mio caso d'uso, che preferirei attenersi ad essa)