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

Zakhar · Le 07/03/2020, à 15:57

Y'en a qui suivent !

Corrigé, merci.

jaxx21 · Le 10/03/2020, à 09:06

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, à 09:13)

Zakhar · Le 10/03/2020, à 16:51

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, à 22:43)

Zakhar · Le 17/03/2020, à 22:08

(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, à 11:59)

Zakhar · Le 27/03/2020, à 14:21

[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.

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, à 18:19)

Zakhar · Le 27/03/2020, à 18:17

(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, à 18:22)

NOLAK · Le 13/04/2020, à 09:57

Bonjour, merci pour votre programme, il fonctionne à merveille !
Il m'arrive très souvent de copier des fichiers avec des caractères interdits, souvent ' (ex : l'arme, j'aime).

Le problème du coup est qu'il faut renommer les fichiers et dossiers avant la copie. Avez vous un moyen pour contourner problème sans renommer ?

Merci d'avance pour votre aide.

Zakhar · Le 13/04/2020, à 10:33

Bonjour et merci pour ton intérêt.
Ce n'est pas si simple car ça ne concerne pas uniquement la copie de fichiers (dans le sens upload vers le cloud), mais la même limitation s'applique aux renommages (fichiers et répertoires) et aux liens durs (commande ln, appelée "copie" chez un fichier).

Il existe des solutions (mais aucune de codée jusque là). Par exemple ce que fait rclone, c'est à dire remplacer automatiquement les caractères interdits par des caractères alternatifs.

Par exemple, remplacement de

l'arme

en

l＇arme

C'est à dire le caractère 0x27 est remplacé par la séquence unicode alternative : 0xef 0xbc 0x87

Ce faisant cela pose 2 autres problèmes :
- le nom qui était de longueur acceptable (250 caractères pour 1fichier) peut devenir trop long
- il est possible qu'il existe déjà un fichier ou répertoire avec le nouveau nom, cela n'aura pas été filtré par le kernel avant l'appel du driver, et c'est donc une condition de plus à tester.

Ce deuxième problème est un peu "sioux". Supposons qu'on remplace "L'arme" par "L_arme".
Si tu as déjà un fichier nommé "L_arme" dans ton répertoire et que tu veux maintenant copier (upload) un fichier nommé "L'arme", pour le kernel il s'agit de noms différents et donc tout va bien, tu as le droit d'avoir dans ton répertoire les deux fichiers. Donc le kernel va joyeusement appeler le driver, lequel va opérer la substitution et créer un doublon... Ce n'est pas dramatique pour 1fichier car on a le droit d'avoir des doublons, mais au niveau des répertoires locaux ça casse pas mal de choses !..

Il faut noter aussi que ces caractères interdits ne le sont que pour l'API. Ils ne sont pas du tout interdits sur l'interface web où ça ne pose pas de problème d'avoir un fichier "L'arme".

Donc l'idéal serait que l'interdit soit levé dans l'API ... je peux demander à la team 1fichier.

Si l'interdit n'est pas levé, le remplacement comme rclone pose le problème de longueur. On pourrait alors remplacer tous les interdits par '_' ce qui lève ce problème, mais dans tous les cas il reste le sujet du fichier/répertoire déjà existant.

Quelle solution préférerais-tu si l'interdiction dans l'API ne peut pas être levée ?
- Remplacement par des séquences qui donnent un caractère ressemblant (double problème avec l'histoire de la longueur du nom)
- Remplacement par un caractère fixe comme '_'

Question 2, si un doublon est créé, on fait quoi :
- on retourne "fichier existe déjà"
- on laisse passer et on crée le doublon

Cette question 2 est moche. Dans tous les cas on crée un comportement "non cohérent" en ayant changé automatiquement le nom. Supposons prenne l'option d'éviter les doublons et donc répondre "fichier existe déjà", tu vas avoir un répertoire contenant "L_arme", tu essaye de copier "L'arme" et on te dit "fichier existe déjà"... alors que visiblement ce n'est pas le cas. C'est moche non ?

... en attendant je pose la question à la team 1fichier en parallèle.

Le "moins moche" si je devais implémenter un truc serait à mon sens :
- remplacer tous les caractères interdits par '_'
- ne pas créer de doublons.

Cela produit certes les incohérences signalées, mais c'est le prix du remplacement automatique. C'est jouable comme incohérence pour la fonctionnalité ?

A noter : sont aussi interdits les espaces (espace ou assimilés comme CR, LF, tab, etc) en début et en fin de nom de fichier, mais là on est cohérent car c'est aussi interdit sur l'interface web, et on n'a donc pas les deux problèmes cités plus haut

Dernière modification par Zakhar (Le 13/04/2020, à 10:50)

NOLAK · Le 13/04/2020, à 11:50

Merci Zakhar pour ta réponse,

Zakhar a écrit :

Il faut noter aussi que ces caractères interdits ne le sont que pour l'API. Ils ne sont pas du tout interdits sur l'interface web où ça ne pose pas de problème d'avoir un fichier "L'arme".

Je ne peux pas créer un dossier "l'arme" dans l'interface web : Nom du répertoire invalide #225

Mon problème est quand tu passes par des programmes qui organise automatiquement dossiers et fichiers, qu'ils nomment justement le dossier "l'arme" et la je me retrouve avec une copie en erreur.
Ce qui serait intéressant du coup c'est que dans le montage l'affichage ressemble à "l'arme" et coté serveur 1fichier à "l_arme" (ou autre caractère qui correspond à ' )

Mon lien est référencé dans mon dossier local sur le programmes du type :

/monDossierLocal/l'arme/l'arme.txt

et quand je veux faire un copie ou déplacer depuis le programmes sur 1fichier, je vais me retrouver comme ça :

/1fichier/l'arme/l'arme.txt

Mais la je suis en erreur alors ma solution actuellement est de modifier le nom du dossier du fichier et le lien de référence dans le logiciel ce qui devient long quand on n'a beaucoup de fichiers.

Du coup je ne sais pas trop ce qu'il est possible de faire, le remplacement par séquences me semble intéressant.

Zakhar · Le 13/04/2020, à 13:11

Ok je vois, donc c'est plus compliqué que j'imaginais mais je reformule pour vérifier que j'ai bien compris.

Tu voudrais en gros qu'on puisse utiliser les "caractères interdits", quitte à les "escaper" dans quelque chose qui est autorisé côté 1fichier.

Du coup la substitution avec un caractère de remplacement unique n'est pas possible car elle n'est pas bijective.

Donc en gros on va remplacer dans un sens les ' (apostrophe 0x27) par la séquence alternative 0xef 0xbc 0x87 qui ressemble visuellement à une apostrophe, histoire qu'on ne soit pas trop perdu si on regarde les pages web.
Dans l'autre sens, quand on lit cette séquence sur le stockage, on la remplace par 0x27 pour avoir à nouveau une apostrophe.

Ça peut marcher comme comportement, et c'est plus simple puisque le kernel va alors filtrer correctement les appels.

Cela aura cependant trois effets négatifs:
- il n'est plus possible de créer un fichier via 1fichierfs avec la séquence de remplacement en entrée.
- cela créera potentiellement des doublons avec les fichiers qui existent déjà sur le serveur puisque ces sept caractères sont autorisés. Cependant l'effet est limité, le doublon ne pourra être créé via 1fichierfs mais uniquement sur le web, or on peut déjà créer des doublons sur le web, donc ce n'est finalement pas trop grave !..
- problème de longueurs de nom déjà signalé plus haut.

Deux effets négatifs avec cette façon de faire me semblent effectivement acceptables :
- Le premier effet est difficile à reproduire (on n'a pas ce caractère au clavier, il faudrait faire un copier/coller pour le générer)
- L'effet doublons existe déjà via le web.

Le sujet de la longueur du nom demeure car la limitation a 250 caractères sera impacté par le remplacement de caractères uniques par une séquence... A l'extrême un nom de fichier/répertoire composé uniquement de caractères interdits sera limité à 83 caractères... c'est l'autre limitation introduite par cela.

Dans ce cas je vais prendre les mêmes séquences que rclone, ce qui pourrait homogénéiser si quelqu'un utilise les deux programmes.

C'est Ok ainsi, y compris les limites ?

P.S. : 1fichier va "homogénéiser", je présume donc interdire aussi sur le web les caractères en question, comme ils le sont déjà pour les répertoires. Cela limitera l'effet "doublons"

Dernière modification par Zakhar (Le 13/04/2020, à 13:14)

NOLAK · Le 13/04/2020, à 14:31

Je ne voyais pas tous les points négatifs mais c'est l'idée même avec les limites mais je ne voudrai pas pénaliser d'autres utilisateurs.

Zakhar · Le 13/04/2020, à 14:45

Ne t'inquiète pas, je vais faire ça comme d'habitude avec des paramètres.

Comme ce que tu demandes fait du sens, ce sera le comportement par défaut.

Par contre il y aura un paramètre du genre --raw-names qui n'effectuera pas la double traduction (comportement actuel).

Si ça "cassait" quelque chose, sans doute quelqu'un l'aurait déjà rapporté. L'usage qui consiste à récupérer les films de vacances de Tonton Jacques, si tonton a utilisé l'interface web pour nommer son film "J'aime les vacances", en faisant la copie par lien (bouton web : "Sauvegarder sur mon compte 1fichier.com"), on a effectivement des caractères "interdits" dans le stockage.
Mais quand on va lire ces caractères interdits, il ne seront pas traduits puisqu'à ce moment là on utilise la traduction inverse, et on verra donc bien le "bon" nom, tel que sur l'interface web.
Si l'utilisateur renomme, du genre : "J'aime les vacances" vers "Tonton : J'aime les vacances", cette fois la traduction sera appliquée sur le stockage et l'apostrophe aura été changée en son caractère alternatif... mais pas dans la vision locale.

Ce fonctionnement-là (sans doute un des plus courants) continuera donc de marcher avec ou sans l'option --raw-names.

Et pour le cas (improbable) où ça "casserait" des choses, il suffira d'ajouter la nouvelle option.

==> Je rajoute à la /TODO list.

Dernière modification par Zakhar (Le 13/04/2020, à 14:46)

NOLAK · Le 13/04/2020, à 15:00

Super ! Merci en tout cas Zakhar, il fonctionne à merveille

Zakhar · Le 15/04/2020, à 18:39

A ma demande, 1fichier vient d'aligner le renommage des noms de fichiers sur l'interface web en interdisant les mêmes caractères que l'API, ce qui limitera les risques de "doublon" ou message inexplicable car un fichier existe déjà sur un nom "alternatif".

Une "subtilité" que je n'avais pas capté, c'est que les 2 caractères " et ' sont en réalité autorisés dans les noms de fichier... mais pas dans les répertoires.

J'ai demandé s'ils pouvaient aligner, mais pas de réponse pour le moment.

1fichierfs interdit pour le moment les noms de fichier avec ces deux caractères, je vais corriger ça aussi.

Par contre @Nolak, je comprends que tu en as aussi besoin pour les noms de répertoires, donc il va falloir que je fasse l'algorithme global envisagé. S'ils pouvaient autoriser les " et ' dans les répertoires ça permettrait un "patch vite fait" en enlevant juste ces deux caractères de la liste, qui sont sans doute ceux qui te gênent le plus (j'imagine que tu as moins de noms avec des >, des $ ou des \ )... mais l'absence de réponse ne semble pas aller dans ce sens.

Donc un peu de patience !

NOLAK · Le 23/04/2020, à 11:04

Bonjour Zakhar,

Merci encore pour ton aide, Il y a du nouveau depuis ce matin sur 1 fichier

Sur la version web je vais nommer un fichier :

êéà

Du coté de 1fichierfs il ressort :

ÃªÃ©Ã

1fichier serait-il en train de faire des corrections ?

Dernière modification par NOLAK (Le 23/04/2020, à 12:17)

Zakhar · Le 23/04/2020, à 12:20

Bonjour Nolak,

Un peu de lecture au hasard !
https://medium.com/sroze/le-probl%C3%A8 … 625d132b8f

C'est un problème d'encodage, sans doute de ton côté.

Les caractères stockés sur 1fichier sont bien des é et à, mais tu regardes "derrière" 1fichierfs avec un afficheur qui ne fait pas de l'UTF-8 mais par exemple avec la mauvais O.S. W$ qui en est toujours en Windows-1252 (mauvaise interprétation de l'ISO-8859-1, parce que M$ se refuse d'utiliser les normes internationales préférant les siennes).

Pour vérifier, une fois que tu as renommé avec è à sur le web, peux-tu :
- Rafraichir la page web et vérifier que ce sont bien ces caractères qui apparaissent.
- Si tu utilises un mauvais navigateur (du genre Internet Explorer/Edge), faire la même vérification avec un bon navigateur du genre Firefox, Chromium
- Une fois vérifié que tout va bien côté web, ouvrir un terminal sous Linux et faire un listage du répertoire contenant les fichiers, exemple ci-dessous

$ ls -l ~/1fichier/Divers/Test/
-rw-rw-r-- 1 alain alain 1073741824 févr. 16 11:15 /home/alain/1fichier/Divers/Test/test_1G_éà_1
-rw-rw-r-- 1 alain alain 4294967296 mars  15 08:40 /home/alain/1fichier/Divers/Test/test_4G_ê_1

- Et aussi afficher ta "locale" pour vérifier que tu es bien en UTF-8 (sinon c'est sûr tu auras le "problème")

$ echo $LANG
fr_FR.UTF-8

Donc si tout va bien de ce côté là, et que ton usage est de "re-partager" le montage 1fichierfs via Samba pour qu'il soit accessible aux postes W$ de ton raison, pour les raisons invoquées plus haut (W$ à la traîne sur UTF-8), il faut chercher du côté des paramétrages de ton serveur Samba

Si l'affichage des caractères que tu expliques est dans un "logiciel", idem, vérifier que ce "logiciel" s'attend bien à lire de l'UTF-8 !..

Démonstration.
Le caractère é correspond au "codepoint" Unicode \u00E9
Codé en UTF-8, cela donne la séquence de 2 caractères : 0xC3 0xA9
Donc si tu regardes cette séquence 0xC3 0xA9 avec un "lecteur" UTF-8, il va bien faire la traduction inverse sur un "codepoint" E9 et afficher le glyphe: é
Maintenant, si tu regardes la même séquence 0xC3 0xA9 avec un "lecteur" ISO-8859-1 (ou sa version W$) tu vas obtenir 2 caractères du jeu ISO-8859-1 qui sont Â et ©
CQFD

Bienvenue dans les joies de l'encodage.

Et donc sans doute : problème de logiciel client (ie de ton côté)

Edit: sinon le développement de la "traduction" avance bien. J'ai du refaire pas mal de code dans la partie "reprise après arrêt" à cause du fait que les caractères interdits ne sont pas les mêmes pour les fichiers et répertoires, et notamment l'apostrophe qui te gêne. Le code est presque fini, j'en ai profité pour "réparer" des bugs (dans lesquels je n'étais pas encore tombés !) comme par exemple éviter de couper une séquence UTF-8 !.. J'en ai aussi profité pour continuer de "nettoyer" certaines parties du code et faire des améliorations.
Avant de le mettre en package, quand le code sera fini, je suis aussi en train d'étoffer le jeu de tests de non régression pour qu'il puisse aussi tester les cas d'écriture de fichiers.
Et comme c'est une version assez importante vu l'étendue des modifications, elle restera au moins une semaine en test à la fois sur mon PC et sur mon Raspberry Pi 4 avant que je vous la propose.
Bien sûr, elle sera sur le Gitlab pendant ces tests, donc si vous voulez compiler par vous-mêmes c'est toujours bien sûr possible !

Dernière modification par Zakhar (Le 23/04/2020, à 12:49)

NOLAK · Le 23/04/2020, à 13:06

En effet ça me le fait depuis sftp mais pas le terminal et comme c'est arrivé d'un coup donc je me suis posé la question.
J'ai redémarré le logiciel et c'est rentré dans l’ordre.

Pour en revenir à ton message d'avant, oui c'est les apostrophes qui gênent le plus, il est possible d'avoir beaucoup d'apostrophes sur les noms de fichiers de tonton Jacques (surtout quand il part sur une île !), je ne pense pas qu'il utilisera d'autres caractères interdits.

Zakhar · Le 23/04/2020, à 13:21

NOLAK a écrit :

En effet ça me le fait depuis sftp mais pas le terminal et comme c'est arrivé d'un coup donc je me suis posé la question.
J'ai redémarré le logiciel et c'est rentré dans l’ordre.

Ok, donc c'était bien le logiciel client qui était en ISO-8859 !.. Impec si un redémarrage du logiciel client (sftp) a réglé le problème.

NOLAK a écrit :

Pour en revenir à ton message d'avant, oui c'est les apostrophes qui gênent le plus, il est possible d'avoir beaucoup d'apostrophes sur les noms de fichiers de tonton Jacques (surtout quand il part sur une île !), je ne pense pas qu'il utilisera d'autres caractères interdits.

Oui, j'avais bien intuité cela !
Pour les noms de fichiers, la solution facile aurait été de coder comme pour un répertoire, en remplaçant l'apostrophe par une séquence de 3 caractères UTF-8. Seulement, cela aurait diminué inutilement la taille possible d'un nom de fichier.
A l'extrême, un nom de fichier composé uniquement d'apostrophes (cas d'école !) aurait été limité à 83 caractères au lieu de 250.
Pour éviter cela, le codage se fait bien selon les caractères interdits pour les fichiers (l'apostrophe est autorisée pour un fichier), mais les informations de reprise qui sont stockées dans des noms de répertoire subissent un deuxième codage plus efficace des apostrophes et guillemets (double quote) afin de ne pas réduire la limite de longueur des noms de fichiers.
Donc pour le "cas d'école", il sera bel et bien possible de nommer un fichier avec 250 apostrophes (ou un mélange de 250 ' et "), et la fonction de "reprise" reste opérationnelle.

C'est ce deuxième codage, en plus des changements, améliorations, "nettoyage", qui prend un peu de temps à coder et bien tester.

Par contre pour les apostrophes dans les noms de répertoire, là il n'est rien que 1fichierfs puisse faire, puisqu'elles restent interdites. Donc chaque apostrophe prend 3 caractères (au lieu de 1) sur la longueur autorisée de 250 caractères.

Dernière modification par Zakhar (Le 23/04/2020, à 13:24)

Zakhar · Le 27/04/2020, à 11:13

@Nolak

Quelques news :

- Le développement de la fonctionnalité est achevé.Tâche terminée
- Je vais prochainement le "pusher" sur le gitlab (pour ceux qui veulent tester !) [Edit] C'est fait, version 1.7.0
- Il va passer en test sur mes PC pendant environ une semaine. [Edit] Installation faite sur mon PC de bureau et mon Raspberry Pi4
- Il faut aussi mettre à jour la documentation avec une explication sur la "traduction" des caractères.[Edit] Tâche terminée + push sur GitLab
- Ensuite je ferai un package contenant la nouveauté.
- En parallèle je continue à enrichir le jeu de test, surtout avec la partie "écriture" qui est actuellement vide dans les tests.

Au passage j'ai corrigé deux bugs mineurs :
- dates décalées d'une heure en heure d'été
- erreur "accès interdit" quand on supprime un fichier complètement uploadé qu'on a créé dans la session, et qu'on le recrée avant un refresh (autrement dit... faut vraiment tomber dessus en faisant exprès !)

A l'étude (il faut que je voie comment on fait ça sur le PPA [Edit] je pense qu'il faut juste que je "pousse" un package avec "focal" et ça devrait marcher) un packaging aussi pour la version 20.04 qui vient de sortir.
A mes premiers tests, ça fonctionne "out of the box" sur la 20.04 (cette version m'a fait une première impression excellente, contrairement à la 18.04, avec l'extension "Unite", ça devrait être quasiment aussi bien que Unity ! )

Dernière modification par Zakhar (Le 27/04/2020, à 21:44)

NOLAK · Le 28/04/2020, à 06:49

Merci zakhar pour ton travail, il est en test depuis hier ça fonctionne très bien.

Zakhar · Le 28/04/2020, à 07:39

NOLAK a écrit :

Merci zakhar pour ton travail, il est en test depuis hier ça fonctionne très bien.

Bravo, tu as compilé depuis le source ?

(Ça fait peur à beaucoup, mais en réalité c'est 3 lignes de commande...
- Installer les 2 dépendances fuse/curl [à faire une fois pour toutes]
- faire un git clone
- faire make 1fichierfs)

N'hésite pas à remonter si tu vois des bugs... il est possible qu'il en reste sur le code nouveau malgré mes propres tests !..

D'ailleurs si tu as compilé depuis le code source, pour aider au debug si jamais il y des choses bizarre, tu peux faire tourner en "mode debug", pour cela :

make 1fichierfs DEBUG=1

Et il faut lancer 1fichierfs avec le niveau de trace "debug" (7) qu'on met dans un fichier à part (sinon ça va submerger la syslog!)

1fichierfs --log-level=7 --log-file=/tmp/debug_1fichierfs.txt  --api-key=@1fichier.key [... autres options.. ] mountpoint

Avec le niveau 7, la trace est très (très !) verbeuse et aide à debugger.
Une compilation spécifique comme indiquée ci-dessus est nécessaire car les packages ne sont pas en mode DEBUG pour alléger l'exécutable de tous les messages qui sont nécessaires à ce mode.
De fait, l'exécutable "debug" sera donc un peu plus gros.

Si l'exécutable n'a pas été compilé en mode 'debug' l'application du niveau de log 7 (debug) n'est pas opérationnel et sera traduit en niveau 6 avec un message dans la log en ce sens.

Dernière modification par Zakhar (Le 28/04/2020, à 07:53)

NOLAK · Le 28/04/2020, à 08:53

Zakhar a écrit :

Bravo, tu as compilé depuis le source ? big_smile

Oui, c'est une première pour moi, un peu de mal à comprendre mais finalement c'est simple
je l'ai refait avec le debug, pour le moment je n'ai rien eu de bizarre.

Je te tiens au courant

Zakhar · Le 28/04/2020, à 12:05

Alors bravo si en plus c'était une première !

Il y a effectivement des bugs, mais tu n'es sans doute pas tombé dedans.
Par exemple renommer un fichier qui n'a pas fini son cycle d'upload si le nom était très long (plus de 200 caractères) et devient très court. Cela peut provoquer un crash à cause d'un test inversé.
La suppression future d'un fichier (cas rare) était aussi buggée.
Aussi le deuxième bug signalé comme corrigé ci-dessus ne l'est pas vraiment... je cherche.

Pour un usage "simple" ça devrait marcher en l'état, mais je ferai le package avec les corrections en cours.

Dernière modification par Zakhar (Le 28/04/2020, à 12:15)

Zakhar · Le 04/05/2020, à 21:38

(4 Mai 2020) Version 1.7.0

Nouveautés par rapport à la 1.6.5.3

Nouveau : traduction des caractères interdits (comportement par défaut) avec l'option --raw-names pour le comportement précédent sans traduction.
Nouveau : le package est désormais aussi produit pour la toute dernière LTS : 20.04 Focal Fossa.
Crash fix : 'use after free' dans l'algorithme de récupération de jetons de téléchargement alternatif.
Bug fix (parallélisme) : dans certains cas écriture petit fichier + suppression immédiate, tentative de supprimer un répertoire non créé.
Bug fix (parallélisme) : Upload de fichiers puis suppression et sortie immédiate du programme : dans certains cas, les fichiers n'étaient pas supprimés.
Bug fix : les dates ne sont plus décalées d'une heure en horaire d'été.
Bug fix : erreur "accès interdit" quand on supprime un fichier complètement uploadé qu'on a créé dans la session, et qu'on le recrée avant un refresh.
Bug fix mineur : amélioration du rafraîchissement en cas d'erreur sur la suppression des répertoires "metadata".
Test : très largement augmenté les cas de test (environ 200 tests de non régression s'enchaînent).
Optimisations et qualité de code : refonte de l'algorithme "metadata" plus simple et plus clair.
Documentation : mise à jour de la documentation pour expliquer la traduction de caractères. Commande : man 1fichierfs

ATTENTION: si vous utilisez 1fichierfs pour copier des fichiers vers votre stockage (upload), assurez vous avant la mise à jour que le répertoire .upload.1fichierfs (à la racine) est bien vide et ne contient aucun fichier ni répertoire. S'il contient des répertoires supprimez-les. S'il contient des fichiers ce sont des fichiers que vous avez "uploadé" et qui se sont "perdus en route". Regardez s'ils sont importants ou pas, au besoin sauvegardez les ailleurs et supprimez tout ce qui est dans le répertoire en question.
En effet, ce répertoire est le répertoire cible pour les upload FTP. Le "marquage" avec des répertoires sert à faire la "reprise" si vous avez arrêté 1fichierfs (ou votre PC) avant qu'un cycle de téléchargement soit terminé. Or l'algorithme de nom de répertoire a changé pour tenir compte de la traduction, et s'il reste des répertoires créés avec la version d'avant (1.6.5.3), il est possible que le programme renomme mal les fichiers ou carrément crashe.

Si vous n'uploadez pas de fichier avec le driver, vous n'êtes pas concernés par cette précaution !

Mise à jour recommandée: compte tenu des bug corrigés !
Attention cependant: le comportement précédent s'obtient en rajoutant l'option --raw-names qui ne cherche pas à "traduire" les noms de fichiers, et donc vous retournera des erreurs si vous utilisez des caractères interdits par 1fichier.com (comme auparavant).

Désormais, le comportement par défaut (suggestion de @Nolak) est de "traduire" les caractères interdits par 1fichier ($ < > \ `) + (" ') pour les répertoires, dans des caractères visuellement proches pour que quand vous regardiez sur la page web vous ne soyez pas perdus. Ce comportement est le même que rclone, ce qui vous offre une meilleure compatibilité si vous utilisez les deux solutions.
Cette traduction automatique et transparente vous permet d'utiliser des programmes clients qui veulent nommer des fichiers/répertoires avec ces caractères.

Par exemple vous pouvez essayer :

cp money "J'aime/Les $ous : <3"

Le fichier cible contient en l'occurrence 2 caractères "interdits" pour 1fichier.com (< et $) et le répertoire contient un ' qui est interdit.
Avec la nouvelle version tout cela fonctionnera et sera "traduit" de façon transparente.

Seul point négatif de la "traduction", elle réduit la longueur disponible pour les noms de fichiers et répertoires qui autrement est de 250 caractères.

Pour tous les détails, vous pouvez toujours consulter le manuel livré avec le package :

man 1fichierfs

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

$ stat -c "%s %n" 1fichierfs_1.7.0~buster-1_armhf.deb; sha256sum 1fichierfs_1.7.0~buster-1_armhf.deb; md5sum 1fichierfs_1.7.0~buster-1_armhf.deb
78636 1fichierfs_1.7.0~buster-1_armhf.deb
2d6b8f6680fb2572a8bb13bb2789369a73da74bb8831d10979f4412bbd79fd4d  1fichierfs_1.7.0~buster-1_armhf.deb
b15940262d3ac0b47e8a795fdb6c59fe  1fichierfs_1.7.0~buster-1_armhf.deb

Suite : suite à une "correction" chez 1fichier.com, je dois faire une "protection" pour éviter les erreurs 403 en cascade si par exemple vous avez uploadé plein de petits fichiers vers un répertoire, puis coupé 1fichierfs avant que les fichiers soient en place... et ensuite supprimé sur l'interface web le répertoire cible. Dans ces conditions, cela va générer des 403 en cascade qui sont susceptibles de provoquer un bannissement temporaire... mais bon quand on fait ce genre de manipulation douteuse... Le problème aussi est que cela se répéterait à chaque démarrage, sauf suppression des fichiers dans .upload.1fichierfs dans l'interface web.

Dernière modification par Zakhar (Le 05/05/2020, à 09:54)

Zakhar · Le 17/05/2020, à 12:05

(17 Mai 2020) Version 1.7.1

Nouveautés par rapport à la 1.7.0

Nouveau : au démarrage, attend que le réseau soit prêt plutôt que de sortir en erreur.
Typo : il manquait deux sauts de ligne dans l'aide (option -h).
Documentation : mise à jour de la documentation avec le nouveau paramètre --network-wait (défaut : 60 sec). Commande : man 1fichierfs

Mise à jour ?
La modification est mineure, et surtout pour un meilleur fonctionnement sous Ubuntu 20.04 (et également sous Raspbian)

Explication : pour être plus "réactives", notamment au démarrage, les distributions modernes n'attendent plus que le réseau soit totalement prêt pour lancer la session. C'est fort efficace car la Ubuntu 20.04 démarre en moins de 10 secondes tandis que mon ancienne 16.04 met 26 secondes. L'amélioration (sur la même machine, donc c'est vraiment comparable) est tout à fait sensible.

Inconvénient : je démarre 1fichierfs à la mise en session (programmes au démarrage) de façon à ce qu'il soit lancé avec le compte de l'utilisateur. En effet, il est non recommandé de lancer des montages fuse en "root" au démarrage de la machine (/etc/fstab par exemple). Comme il s'agit d'un PC de bureau, la session est lancée automatiquement pour éviter d'avoir à passer par l'écran avec mot de passe. Or dans ces conditions, 1fichierfs ne se lançait pas car au moment où la session démarre, le réseau n'est pas encore totalement prêt et cela faisait sortir 1fichierfs en erreur : erreur sur la lecture de la "racine" du montage.

Avec ce nouveau comportement, il n'y a plus de problème. 1fichierfs va attendre par défaut jusqu'à 1 minute avant d'abandonner et sortir en erreur. Sur mon PC de bureau, en pratique il attend 2 secondes, et 8 secondes sur le Raspberry Pi dont la Raspbian fait la même chose.

Il s'agit donc d'un changement de comportement par rapport à la version précédente, mais c'est plus logique, et ressemble par exemple à l'option _netdev du /etc/fstab. Pour retrouver le comportement précédent, on peut rajouter à la ligne de commande :

--network-wait=0

Ainsi, en cas d'erreur réseau au démarrage, 1fichierfs ne cherchera pas à "ré-essayer", mais sortira tout de suite en erreur.
Vous pouvez aussi bien sûr mettre une durée différente du défaut à 60 secondes si c'est trop/pas assez selon votre configuration et votre goût.

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

$ stat -c "%s %n" 1fichierfs_1.7.1~buster-1_armhf.deb; sha256sum 1fichierfs_1.7.1~buster-1_armhf.deb; md5sum 1fichierfs_1.7.1~buster-1_armhf.deb
79748 1fichierfs_1.7.1~buster-1_armhf.deb
5173257d4b52783ace2688209a73397884f3a03bffbcf1e5f191971e3eb9d2a5  1fichierfs_1.7.1~buster-1_armhf.deb
7dba19f91c465a6b3a7b314b0091eee5  1fichierfs_1.7.1~buster-1_armhf.deb

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

Ubuntu-fr

Navigation

Liens de recherche

Annonce

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

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

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

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

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

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

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

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

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

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

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

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

#232 Le 13/04/2020, à 09:57

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

#233 Le 13/04/2020, à 10:33

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

#234 Le 13/04/2020, à 11:50

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

#235 Le 13/04/2020, à 13:11

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

#236 Le 13/04/2020, à 14:31

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

#237 Le 13/04/2020, à 14:45

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

#238 Le 13/04/2020, à 15:00

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

#239 Le 15/04/2020, à 18:39

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

#240 Le 23/04/2020, à 11:04

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

#241 Le 23/04/2020, à 12:20

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

#242 Le 23/04/2020, à 13:06

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

#243 Le 23/04/2020, à 13:21

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

#244 Le 27/04/2020, à 11:13

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

#245 Le 28/04/2020, à 06:49

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

#246 Le 28/04/2020, à 07:39

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

#247 Le 28/04/2020, à 08:53

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

#248 Le 28/04/2020, à 12:05

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

#249 Le 04/05/2020, à 21:38

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

#250 Le 17/05/2020, à 12:05

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

Pied de page des forums