Contenu | Rechercher | Menus

Annonce

Ubuntu-fr vend de superbes t-shirts et de belles clés USB 32Go
Rendez-vous sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#226 Le 07/03/2020, à 16:57

Zakhar

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

Y'en a qui suivent !

Corrigé, merci. big_smile


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#227 Le 10/03/2020, à 10:06

jaxx21

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

Un gros gros merci à toi. C'est vraiment génial ce que tu nous a offert. J'y connais rien en code, api et tout ca, mais je sais que ca sert beaucoup. Merci à toi.
Je ne sais plus si on en a déja parlé mais pour le déplacement d'un dossier, je crois que ce n'est pas possible?

en tout cas merci.J'adore.Je viens de mettre à jour avec la dernière version.

Dernière modification par jaxx21 (Le 10/03/2020, à 10:13)

Hors ligne

#228 Le 10/03/2020, à 17:51

Zakhar

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

Bonjour Jaxx21.

Réponse courte : oui, il est tout à fait possible de déplacer un répertoire, c'est prévu par les APIs et codé depuis très longtemps dans 1fichierfs (précisément la 0.9.7 du 18 janvier 2019) !..

Réponse un peu plus détaillée : il existe même 3 cas, que ce soit pour les répertoires ou les fichiers, et tous les cas sont codés et même dans le jeu de test de "non régression". Les trois cas sont :

  • Changer le nom de l'objet (fichier ou dossier)

  • Déplacer l'objet dans un autre répertoire.

  • Déplacer l'objet dans un autre répertoire et sous un autre nom (cumul des deux opérations ci-dessus en une seule opération).

En pratique, "à la souris" tu ne pourras faire que les deux premiers cas. En ligne de commande on peut facilement aussi faire le dernier cas, un truc du genre :

mv foo bar/foobar

Tout cela fonctionne via l'API, du reste plus "proprement" avec les répertoires où une seule API couvre les 3 cas, alors qu'avec les fichiers il faut utiliser 2 APIs différentes.

Il y a aussi certaines limitations pour déplacer des répertoires sur des partages reçus, il faut notamment que le partage ait autorisé l'écriture.
Tu ne peux pas nom plus donner en cible de déplacement des noms réservés par 1fichierfs comme le répertoire d'upload, ou comme les noms que tu spécifies en option pour les statistiques ou le fichier de "refresh".
Pour le renommage, les caractères du nouveau nom choisi ne doivent pas inclure de caractères interdits dans l'API (par exemple : < > $ " ' etc...)


Réponse longue :
Si comme moi tu utilises encfs "par dessus" 1fichierfs pour chiffrer des fichiers personnels, les déplacements/renommages ne vont pas forcément fonctionner, selon les options utilisés pour encfs.
En effet, dans la meilleure option pour la sécurité, encfs utilise une clé différente pour chaque fichier. La clé dépend du chemin absolu du fichier dans le montage.
Par conséquent, renommer ou déplacer un fichier changeant son chemin absolu, la clé change. Pour n'avoir pas à ré-écrire tout le fichier, encfs ré-écrit juste la partie de quelques octets qui lui permet de trouver la clé initiale de chiffrement.
Mais on est alors là dans une opération qui n'est plus un renommage/déplacement, mais une opération d'écriture aléatoire à l'intérieur d'un fichier qui n'est pas supportée par 1fichierfs.
En effet, comme le serveur n'offre pas cette possibilité, écrire "quelques octets" sur un fichier de plusieurs giga ne peut se faire qu'en ré-écrivant la totalité donc un cycle entier download/upload de plusieurs giga pour changer quelques octets... pas très cool !..

Donc si tu es dans ce cas, malheureusement c'est plus la limitation : "pas d'écriture aléatoire" qui bloque.

Aussi, le renommage/déplacement d'un répertoire contenant beaucoup de fichiers avec encfs peut s'avérer très long puisque encfs va devoir réécrire les clés de chacun des fichiers de l'arborescence renommée, et même au dessus d'un disque standard, ça peut prendre beaucoup de temps. Ce cas là est donc plutôt une limitation de encfs que de 1fichierfs !

Dernière modification par Zakhar (Le 17/03/2020, à 23:43)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#229 Le 17/03/2020, à 23:08

Zakhar

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

(14 Mars 2020) Version 1.6.5.2

Nouveautés par rapport à la 1.6.5

  • Crash fix : correction d'un crash systématique lors de la suppression d'un fichier écrit mais pas encore sur le "storage". Cause : buffer trop court !

  • Bug fix : empilement des buffers en entrée de lecture et suppression du buffer interne corrigé. Peut-être cause de rares bugs de lecture : boucle sans fin, rare crash.

  • Améliorations : meilleure résilience du renommage en fin de process d'upload, simplification de la suppression dans le process upload, l'utilisateur peut renommer des répertoires/fichiers dans le répertoire upload.


Mise à jour: il s'agit maintenant de correction de bugs. Donc vous devriez mettre à jour, même si vous n'avez jamais rencontré les bugs corrigés, ils pourraient survenir dans certains cas d'usage particuliers.

Raspberry Pi (Raspbian Buster 32 bits): 1fichierfs_1.6.5.2~buster-1_armhf.deb (taille : 76308 octets)

Checksums:

$ md5sum 1fichierfs_1.6.5.2~buster-1_armhf.deb
cec618a92cb43991f0a233461e144254  1fichierfs_1.6.5.2~buster-1_armhf.deb
$ sha256sum 1fichierfs_1.6.5.2~buster-1_armhf.deb 
b9c544905f59f49d00f29c7390406e51765f466ebc39ac3711886c8c86defd43  1fichierfs_1.6.5.2~buster-1_armhf.deb

Suite : la gestion des erreurs dans la partie écriture est assez déficiente (pour ne pas dire totalement foireuse ou inexistante !). Bien souvent s'il y a une erreur d'écriture, il vous faudra juste "tuer" le programme. C'est une partie un peu plus difficile à mettre au point, car il faut provoquer des erreurs exprès pour debugger, et il faut imaginer dans le code les erreurs qui pourraient bien se produire pour réagir de façon adéquate.
Il reste aussi un cas de bouclage sur erreur en lecture, sans doute lié à partiellement à un défaut d'écriture.
Enfin, tant qu'il n'y pas d'erreur (erreur réseau, time outs, compte FTP supprimé, etc....) tout va bien sur l'écriture. Et si une erreur se manifeste, le plus simple pour l'instant est de couper le programme, relancer, et refaire l'écriture.

Dernière modification par Zakhar (Le 18/03/2020, à 12:59)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#230 Le 27/03/2020, à 15:21

Zakhar

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

[Windows 10]
Comme vous le savez, l'O.S. de Redmond étant de plus en plus cantonné en entreprise, on en trouve de moins en moins chez les particuliers (à l'exception des gamers) qui abandonnent complètement leur PC au profit de tablettes ou smartphones, ou bien utilisent des Mac ou Linux en proportion bien plus grande que les entreprises.

Pour éviter de devenir complètement obsolète, Redmond a commencé à intégrer de plus en plus de Linux dans son O.S.

Cela a commencé avec WSL (le 1) qui était une couche d'émulation de Linux, un peu similaire à ce que Wine est sous Linux. Amusant quand vous y pensez !..

En maintenant nous en arrivons à WSL2 : https://devblogs.microsoft.com/commandl … sion-2004/

Cela devrait être disponible non pas en 2004 comme on pourrait le croire... mais (20)20/04 [Oui, même nommage que les versions Ubuntu !], donc en avril de cette année, moyennant un possible retard (crise sanitaire, bugs, etc...)

Il s'agit d'un "vrai" kernel cette fois qui tournera en mode virtualisé, ce qui veut dire qu'il ne devrait pas y avoir de problème à y faire tourner 1fichierfs

Reste ensuite la question d'exposer ce filesystem à l'hôte si vous voulez vous servir des outils installés sur l'hôte (VLC, etc...), mais c'est là un problème générique de virtualisation qui aura sans doute une solution (au moins en exposant un partage SMB, même si c'est moche !..)


Donc aucun "portage" natif ne sera envisagé, puisque le cours normal des choses est que Linux continue de se développer partout. tongue


Sans doute aussi le développement de Linux partout pourrait être aidé si se confirme la rumeur de "O.S. as a service" (c'est à dire avec un "abonnement mensuel") qui laisse entendre que cela sera le cas aussi pour les particuliers le 30 mars.
J'imagine bien que si les particuliers doivent désormais payer tous les mois pour utiliser leur PC "sécurisé" par Redmond jusqu'à l'EFI... beaucoup vont chercher un peu plus énergiquement à se défaire de ces chaînes et regarder vers le pingouin.


En tout cas, si vous avez une machine avec l'O.S. propriétaire de Redmond, avec WSL2 (insider ou quand il sera "general availability"), vous pouvez bien sûr reporter les éventuels bugs de WSL2-1fichierfs, et aider d'autres personnes dans votre cas en indiquant comment vous avez exposé le filesystem à l'hôte.

Vos contributions sont les bienvenues donc !

Dernière modification par Zakhar (Le 27/03/2020, à 19:19)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne

#231 Le 27/03/2020, à 19:17

Zakhar

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

(27 Mars 2020) Version 1.6.5.3

Nouveautés par rapport à la 1.6.5.2

  • Bug fix : dans certaines rares conditions, la lecture était corrompue. C'était davantage visible avec des outils comme encfs qui vérifient l'intégrité des données.

  • Amélioration : meilleure résistance aux erreurs lors de l'écriture FTP. En cas d'erreur FTP, les "writers" sont libérés correctement, et le programme client n'est plus figé en écriture.

  • Optimisations et qualité de code : les statistiques utilisent maintenant le modèle "relaxed" pour les accès atomiques (ça ne fait aucune différence sur processeurs Intel/AMD, uniquement optimisé sur ARM). Factorisation et amélioration de code pour certains outils utilisés par le programme.


Mise à jour très recommandée: compte tenu du bug possible en lecture, je recommande la mise à jour. C'est sans importance majeure pour la lecture de média, mais pourrait corrompre une restauration de données si vous ne prenez pas le temps de comparer ce qui est copié à l'original stocké.

Raspberry Pi (Raspbian Buster 32 bits)1fichierfs_1.6.5.3~buster-1_armhf.deb

$ stat -c "%s %n" 1fichierfs_1.6.5.3~buster-1_armhf.deb; sha256sum 1fichierfs_1.6.5.3~buster-1_armhf.deb; md5sum 1fichierfs_1.6.5.3~buster-1_armhf.deb
75816 1fichierfs_1.6.5.3~buster-1_armhf.deb
10a324b1f4609ece3f8b1597194a630189b4561cc3daa761673fc0becd49abaf  1fichierfs_1.6.5.3~buster-1_armhf.deb
d1c348f3b1dc679dbae51870dc614a05  1fichierfs_1.6.5.3~buster-1_armhf.deb

Suite : la partie lecture qui est maintenant un peu ancienne a besoin d'un bon coup de jeune de d'amélioration. L'algorithme est complexe (d'où les bugs qui traînent après plus d'un an du début !) et j'ai des idées pour le simplifier tout en l'améliorant avec moins de "locks" et en permettant aussi une adaptation automatique ou pilotée entre stream et lecture aléatoire.

Je vais faire ça sur une "branche" séparée, comme j'avais fait pour la partie écriture, histoire de pouvoir corriger rapidement d'éventuels bugs que vous signaleriez sur la présente version.

Dernière modification par Zakhar (Le 27/03/2020, à 19:22)


"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Hors ligne