llaumgui wrote:Lut,

je déterre un peu le topic.

J'ai pus faire une synchro via DAVFS. Pas de problème mais pour le cryptage ? encrypt m'oblige à avoir une version en claire sur mon DD ce qui me fait doublons.... PAs moyen de faire du lucks ?

Non, les fichiers "en clair" sont une vision théorique, ils ne sont stockés nulle part !
En réalité il est bien évident qu'à un moment donné tu as eu le fichier "en clair"... il a bien fallu que tu le sauvegardes et le chiffres ! Mais une fois chiffré, tu peux supprimer la version "en clair" si ça te chante (et si tu as confiance !).

Encfs fonctionne à partir du répertoire chiffré, qui lui doit exister (en local ou à distance si tu fais comme indiqué sur ce post) et te donne une vision "en clair", mais cette vision est juste la traduction de encfs et n'est réellement stockée nulle part même si ça apparaît dans ton arborescence.

Luks... bah non c'est pas du tout cet usage là !

Avec Nautilus et sans encfs, oui, c'est natif et ça utilise gvfs (module DAV).

Il suffit d'aller dans "Aller à/Emplacement" et donner les coordonnées de ton montage. Ensuite tu mets un signet si tu veux éviter d'avoir à retaper à chaque fois.

Par contre, comme expliqué plus haut, ce n'est pas un réel "montage", mais plutôt un montage au sens Gnome (GIO) qui est donc inutilisable de programmes tels que VLC (par exemple pour lire ta musique directement).
Bien sûr, le contournement consiste alors à copier le fichier de musique sur le disque local et l'y lire... mais c'est moche !

Donc tout dépend de ton "use case" (c'est à dire de ce que tu veux faire exactement) qu'il faut bien que tu précises. Une fois que tu as fait le travail de préciser exactement ce que tu veux faire de ce montage, en général tu as à moitié trouvé la solution !..

Ne confondons pas "solution" et "besoin" ! Le post d'origine ici parle d'empiler un accès DAV avec ENCFS, c'est bien particulier. Si ce n'est pas exactement ce besoin que tu as... eh bien il y a des solutions bien plus simple.

Connais pas fusefs...

Là j'essaye avec gvfs, il marche bien (c'est ce qu'utilise Nautilus) puisque c'est le machin de Gnome, mais la documentation est vraiment à chier... c'est à dire inexistante, il n'est même pas dans le 'man', et lancé avec --help, c'est plutôt laconique !

Avec gigolo, on peut faire un montage visible de Nautilus, et même en faire un signet, mais mon besoin c'est d'y accéder en ligne de commande, ce que ne permet pas la chose (ou je n'ai pas la doc pour le faire).

Si le seul besoin est d'y accéder via Nautilus, Gigolo, un signet, montage, et voila !
Mais comme on n'y a pas accès via un montage "normal", du coup pas possible de faire du encfs par dessus :/

Ah et oui, davfs2 a un comportement désastreux.

C'est ce que j'expliquais plus haut, il a probablement été écrit "mono-thread". Cela fait que lorsque tu es en train de faire un upload (et c'est long en ADSL) les demande de listage (et Nautilus en fait plein sans même que tu le saches !) sont en attente. Par conséquent ton système semble "bloqué", et c'est assez moche. Un autre truc moche, c'est qu'il télécharge tout le fichier dans la cache avant de répondre aux ordres de lecture... ça c'est assez bourrin si on veut juste les premiers octets d'un très gros fichier !..
Si tu veux écrire un file-system Fuse, il FAUT faire un truc multi-tâche (multi-thread) sinon le FS présente le mauvais comportement décrit plus haut. Et si tu te débrouilles bien, il n'y a pas de raison de ne pas pouvoir traiter une demande de listage en parallèle d'une lecture ou d'une écriture.
J'ai fait ainsi sur mon file-system expérimental pour monter une Freebox à distance, et il est très réactif, sans commune mesure avec davfs !..

Et aussi, comme tu le constates, davfs2 utilise effectivement une cache.
Si tu avais suivi le tutoriel en entier, il y a un autre fichier à copier dans ~/.davfs2, c'est celui de la configuration. Ainsi tu peux configurer par utilisateur. Sinon davfs2 prendra le fichier dans son répertoire d'installation et c'est moche !.. Dans ce fichier de configuration tu peux jouer par exemple sur la taille de cache et bien d'autres choses.

Par défaut la cache est dans le répertoire ~/.davfs2/cache, et elle fait 50M.

Lorsque tu "démontes" proprement ton filesystem davfs, il va "synchroniser", c'est à dire qu'il terminera toutes les écritures en court avant de rendre la main. Donc, sauf si tu éteins "sauvagement" ton PC, en principe tout sera uploadé correctement.

Conclusion, compte tenu de l'état de davfs2, son usage est réservé à une manipulation de "petits fichiers", ainsi les effets de bord décrits plus haut n'ont plus trop d'impact.

... et une ré-écriture complète s'impose !.. Je suis dessus, mais j'avance pas vite (j'ai aussi un travail à temps plein et d'autres activités :roll: )

Hello les amis de Fedora,

j'avais déjà regardé la chose (WebDAV + encfs), à l'époque avec Box.net, qui existe toujours est est très fiable, mais n'offre que 5G d'espace gratuit.

Hubic est plus "généreux", mais souffre de grave défauts de jeunesse : dimanche (17 juin 2012) par exemple, c'était planté de 14h00 jusqu'à lundi matin. Fâcheux si on a un besoin urgent de récupérer des données...

Bref, pour apporter ma pierre au moulin de ce post :

-1) davfs2 fonctionne parfaitement en "non-root"... c'est juste un peu "coriace" à mettre en place !
Vous pouvez certainement suivre (et adapter) le processus que j'ai décrit pour Ubuntu ici : http://doc.ubuntu-fr.org/davfs2
Le packaging étant différent sur Fedora, il est possible que le dpkg-reconfigure n'existe pas ou soit fait différemment. A mon avis, le seul truc que fait la commande dans ce cas (à vérifier !) est que ça met le suid de mount.davfs, de façon qu'un utilisateur non root puisse lancer la commande.

-2) je ne connaissais pas wdfs, ça fonctionne mais ça a l'air "pas fini" comme machin (du moins sur Ubuntu). En principe, un file-system qui utilise fuse devrait passer en daemon une fois lancé, sauf si on utilise l'option -f pour le forcer à ne pas le faire. Là, le machin reste constamment au premier plan !.. Donc si on veut faire un script et enchaîner sur le montage encfs, c'est moins évident !..

Je n'ai pas encore bien expérimenté avec wdfs, mais davfs a l'air d'être "écrit avec les pieds" pour ce qui concerne le multi-tâche. En effet, si on lance un transfert volumineux, tout est bloqué, même le listage de répertoire (un simple ls) ... jusqu'à ce que le transfert soit fini. Ca ressemble donc à une sérialisation complète de toutes les actions. Alors c'est sûr que comme ça c'est plus facile à coder, mais du coup ça rend le système très peu réactif, voire donne l'impression que tout est planté.

rsync ne fonctionne pas non plus avec davfs : dans le sens local => cloud, on récupère une erreur 22 (sans doute des caractères mal 'escapés'), dans l'autre sens, cela fonctionne, mais les dates sur le partage webdav sont celles de la création du fichier sur le cloud, et pas la date du fichier d'origine qu'on a copié !.. Donc si on fait une copie local => cloud (cp, puisque rsync ne marche pas dans ce sens !) plus un rsync cloud => local, on se prend une recopie intégrale... pas cool.

Je vais expérimenter avec wdfs, pour voir si outre son côté "pas fini", il présente les mêmes défauts de conception que davfs. Et au pire je tâcherai de me remettre à mon programme de montage distant de la Freebox V6 pour l'adapter à WebDAV !..


[EDIT] : bon, ben pas mieux pour wdfs, voici ce qu'on lit dans le README livré avec le source:

wdfs wrote:limitations of this implementation:
- wdfs is not (yet) multithread safe. it always uses fuse single thread mode.
- read/write of big files (~ 50 MB+) is slow, because the _complete_ file
will be GET/PUT on a request.