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

Jarodd · Le 11/01/2021, à 19:18

Pour 1Fichier je me demande si on peut faire un script qui "appelle" les fichiers tous les mois, genre avec curl. Mais je suppose que ce serait trop facile pour contourner la durée de 60 jours du cold storage
Je regarde Backblaze, qui promet de l'illimité (je cherche le loup), et C14 de Scaleway, qui a l'avantage d'être en France, et ne facturer ni l'archivage ni la restauration, au contraire d''Amazon (qui est souvent cité, mais que je veux éviter).

Jarodd · Le 16/01/2021, à 18:50

Finalement j'ai pris un abo 1Fichier, je verrai pour le cold storage quand j'aurai déjà rempli les 2 To (vu que rien n'est chiffré chez eux, et que je vais pas tout chiffrer chez moi, je n'enverrai pas tout mon contenu).
Je vais donc tester le script 1fichierfs

Zakhar · Le 16/01/2021, à 20:16

Le seul chiffrement utile chez le fournisseur est https, pour éviter que les "boîtes noires" entre toi et le fournisseur n'espionnent ce que tu fais. Ça c'est en place !

Après, le chiffrement tant vanté chez les autres fournisseurs ne sert presque à rien puisque de toute façon le fournisseur doit avoir la clé pour déchiffrer...
Donc ceux qui vantent cela, c'est juste du marketing et du bling bling. Cela protège juste contre des événements improbables du genre vol de disques chez le fournisseur.

Si tu veux chiffrer tes données, le seule chose qui marche c'est le "bout en bout". C'est à dire que tu chiffres à partir de ton PC.

Pour 1fichierfs c'est très simple, tu peux mettre "par dessus" encfs que tu trouveras simplement dans les dépôts.

Ainsi ce qui est stocké sur 1fichier (ou autre fournisseur) n'est qu'une suite d'octets sans signification, et les noms de fichiers et répertoires sont aussi brouillés.

Cela limite cependant à un usage Linux, ou du moins à un système où tu peux faire tourner encfs pour déchiffrer ce qu'il y a sur le stockage. A toi de voir.

Personnellement j'ai les deux. Une partie de mon stockage est "en clair" vis à vis de 1fichier.com (fichiers "publics" on ne contenant rien de personnel/secret) et une autre partie de compte est sauvegardée/lue au travers de encfs, et c'est donc chiffré même pour 1fichier.com

1fichierfs permet de gérer cela "intelligemment" pour éviter le double chiffrement (https + encfs), ce que je fais c'est que je déclare la partie de mon stockage qui est sous encfs en --no-ssl, ainsi elle est accédée en http, ce qui n'a pas d'importance vis à vis des "espions/boîtes noires" puisque de toute façon le trafic est déjà chiffré.

Jarodd · Le 16/01/2021, à 21:11

C'est ce que je comptais faire : le "pas important" en clair, et le "important" en chiffré. Il l'est déjà sur mon disque avec Cryptomator (c'est chiffré mais je suis dépendant d'un programme, l'étape suivante c'est de m'en passer), donc je voudrais envoyer ces fichiers chiffrés.
Mais ni 1fichierfs ni la connexion FTP ne fonctionne.
Pour le 1er, j'ai "noeud final de transport pas connecté" (je n'ai pas encore fait de recherche pour le résoudre).
Pour le second, je suis connecté mais avec l'erreur "553 Droits insuffisants", je ne peux même pas créer un dossier. Et le support est aussi aimable qu'une porte de prison, donc je vais éviter de le solliciter.

Dernière modification par Jarodd (Le 16/01/2021, à 21:11)

Zakhar · Le 16/01/2021, à 23:05

"noeud final de transport pas connecté" c'est un plantage du programme !

C'est le message que tu as quand un driver fuse se plante et laisse le montage en l'air.

Pour libérer le point de montage tu fais un

fusermount -u point_de_montage

Pour m'aider et que je répare, il faut que tu me donnes un journal de ce qu'il se passe.

Donc tu montes avec :

1fichierfs --api-key='Ta_cle_API' -l7 --log-file /tmp/debug.txt point_de_montage

Et tu me postes ce qu'il y a dans le journal (en retirant éventuellement les trucs "confidentiels" si par exemple il y a des noms de fichiers "compromettants" !.. )
Le journal sera où tu l'as spécifié, dans la commande ci-dessus, il sera dans /tmp/debug.txt

Il n'y aura pas les messages de debug si tu as installé à partir de mon PPA, mais ça devrait me suffire pour voir ce qui ne va pas. Si ça ne suffit pas, il faudra que tu partes du source pour la version "debug"... mais on va déjà faire simple pour le moment !

Le plantage est possiblement lié au fait que ton ftp ne fonctionne pas... ce qui est bizarre. Tu as essayé avec ton compte (mail + ton mot de passe) et un truc comme Filezilla ?

Avec Filezilla, le réglage : "Connexion FTP explicite sur TLS si disponible" vers ftp.1fichier.com (port non spécifié = par défaut) et authentification "normale" avec ton mail et le mot de passe que tu as défini (sur la page des réglages FTP du site 1fichier.com) ira bien.

@Jarodd, en tout cas n'hésite pas à poster ici pour toute aide sur 1fichierfs, ou si tu préfères un rapport de bug sur le Gitlab du projet !.. Ou le cas échéant confirmer que cela fonctionne, si ça venait d'un bannissement temporaire de 1fichier.com...

Dernière modification par Zakhar (Le 18/01/2021, à 11:14)

Zakhar · Le 18/01/2021, à 14:04

@Jarodd pourras-tu me dire ce qu'il en est du bug que tu as constaté.

J'ai corrigé un "micro-bug" de date sur la reprise après coupure qui se produisait quand la machine a une date antérieure aux répertoires créés. Cela survient hélas avec le Raspberry Pi car 1fichierfs est lancé au démarrage automatique, à un moment où NTP n'a pas encore mis à jour l'horloge système qui semble coincée à l'heure où on a éteint le Raspberry Pi !..

Tant qu'à corriger des bugs, si tu en as un nouveau, je mets tout dans la corrective 1.8.2 en préparation. Pour l'instant j'attends un peu ton retour avant de la packager.

Dernière modification par Zakhar (Le 18/01/2021, à 14:04)

Jarodd · Le 18/01/2021, à 17:29

Ok je veux bien le faire, mais comment ? Je ne l'ai pas vu passer dans mon update.

Zakhar · Le 18/01/2021, à 18:00

Non le micro-bug n'est pas lié à ce que tu signalais et précisément l'update n'est pas livré en attendant un éventuel autre "bug" dont tu me donnerais des éléments.

Peux-tu me faire une trace comme signalé ci-dessus au post #280 pour que je voies où ça plante ? (si ça plante toujours !)

Pour plus d'aide sur 1fichierfs tu peux toujours faire

1fichierfs --help

Et avec encore plus détail et en français qui détaille chaque option

man 1fichierfs

Aussi me préciser si ton FTP fonctionne par exemple avec filezilla.

En effet "nœud de transport final non connecté" est signe d'un plantage, mais sans autre élément concret à me mettre sous la dent, tu comprends bien que je vais avoir un peu de mal à corriger !

Dernière modification par Zakhar (Le 18/01/2021, à 18:09)

Jarodd · Le 18/01/2021, à 21:04

Concernant mon erreur de droit sur le FTP, c'erst "normal". Trouvé dans l'aide :

Le service FTP de 1fichier.com, ne permet que le dépot de fichiers.
Vous ne pourrez donc pas télécharger des fichiers avec et/ou gerer des dossiers.

Ca s'appelle FTP mais ça ne permet pas de faire du vrai FTP...

Concernant l'erreur que j'avais, je viens de relancer le montage avec 1fichierfs, et cela a bien fonctionné. J'ai créé un dossier, et placé un fichier dedans.
Sur l'interface de 1Fichier > Mes fichiers, je vois le répertoire, mais impossible d'y accéder. Est-ce que vient de la même restriction de droits ? Je pensais avoir une sorte de miroir entre le montage 1fichierfs et l'interface web.
Pour les droits, le répertoire est en 775, le fichier 555 (je suis le proprio de tout). Peut-être une incompatibilité avec les permissions/users côté 1Fichier ?

Comme tu le dis il faut que je commence par le man !

Edit : 10mn après les fichiers envoyés sur mon montage sont apparus. Donc il doit y avoir un cache ou une synchro avec un délai quelque part qui ne les fait pas apparaître immédiatement.

Dernière modification par Jarodd (Le 18/01/2021, à 21:23)

Zakhar · Le 18/01/2021, à 21:24

Parfait donc si le "bug" a disparu.

Il était possiblement dû au fait que tu avais un compte vierge, ce que je peux difficilement tester. Le mieux que je puisse tester est déclarer la racine de montage vers un sous-répertoire vide, ce qui plantait à un moment donné, bug qui m'avait été remonté ici. Mais là j'ai testé, ça fonctionne.

Les permissions des fichiers sont expliquées dans le "man", mais ça ne veut pas dire grand chose pour un montage fuse, sauf si tu précises l'option standard fuse

-o default_permissions

...qui va demander au kernel de vérifier les permissions avant d'appeler le driver.

Le principe est ainsi :
- Les répertoires que tu crées dans ton arborescence 1fichier on tous exactement le même masque de permission que le répertoire de montage.
- Les fichiers ont ce même masque mais sans les bit d'écriture puisque en réalité "l'overwrite" (écriture aléatoire dans un fichier) n'est pas possible de par les possibilités du stockage. Tout ce que tu peux faire c'est effacer un fichier et tout ré-écrire, mais écrire un fichier dépend des bits de permission du répertoire, donc tout va bien.
- Certains répertoires sont protégés en écriture, il s'agit du répertoire d'upload et de tout "partage" que tu reçois en mode "read-only".
- Il peut y avoir des modificateurs pour le masque des droits comme l'option standard des montages : noexec, ou un umask

En réalité les droits "groupe" et "autre" ne servent pas à grand chose car fuse limite l'accès au seul utilisateur qui a réalisé le montage, même root n'a pas accès à tes fichiers !.. L'exception à cela passe par rajouter des options comme allow_other ou allow_root... à condition que tu l'aies déclaré dans la configuration globale de fuse.

A part l'option citée plus haut (default_permissions) où le kernel va intervenir avant le "driver", celui-ci fait ce qu'il veut pour les permissions !.. On peut très bien écrire un driver qui ne te donne le droit d'effacer des fichiers que les jours de pleine lune... mais comme les utilisateurs trouveraient difficile à comprendre on cherche à faire à peu près logique.
Tu noteras cependant, bien que tu ne puisses normalement pas modifier le contenu répertoire .upload.1fichierfs puisque ces bits d'écriture sont à 0, que tu pourras en faire supprimer ou déplacer des fichiers "orphelins" qu'il contient... à condition que ces fichiers soient âgés d'au moins 27 heures ! Ce n'est pas la "pleine lune", mais presque.:lol:
L'explication logique est dans le man, en gros ces fichiers là sont des scories de plantage (ou arrêt brusque du PC) pendant qu'on écrivait des fichiers sur le montage. Et on attend ce délai pour laisser l'utilisateur agir dessus en considérant les limites maximum de 1fichier.com
Tu peux cependant à tout moment jouer avec l'interface web, c'est indépendant !..

Et oui, c'est un exact miroir (presque) entre 1fichier et le montage.
Un répertoire créé/supprimé/renommé par 1fichierfs est immédiatement visible et accessible dans l'interface web (si tu l'utilises sur smartphone : c'est pas fait pour... prend un vrai PC !) car il n'y a pas de notion de "droits POSIX" sur 1fichier.com. Tous les fichiers et répertoires sont à toi !

Un fichier que tu copies via 1fichierfs ne sera pas immédiatement visible sur ton compte 1fichier.com car on utilise FTP qui a 5 minutes de délai plus un temps variable suivant la taille du fichier. Par exemple, un fichier de 10Go copié via 1fichierfs sera visible au bout de 7 à 8 minutes sur ton compte. Il faudra attendre encore une ou deux minutes pour qu'il soit réellement accessible en lecture. C'est d'ailleurs pareil si tu utilises Filezilla pour uploader. Par contre les fichiers uploadés via 1fichierfs sont visibles dans l'arborescence du logiciel. Même pendant le cycle de téléchargement tu peux à tout moment les renommer, déplacer, supprimer. Ils ne sont par contre pas accessibles, limite du fonctionnement de 1fichier.com, tant qu'ils ne sont pas sur le stockage, avec une exception des fichiers plus petits que 4096 octets que 1fichierfs garde en mémoire.

Dans l'autre sens, si tu mets des fichiers directement sur ton compte, il ne seront visible du "miroir" 1fichierfs que lors du prochain "rafraîchissement". En effet, pour des raisons de performance, 1fichierfs mémorise l'arborescence des répertoires que tu as déjà accédés. Il faut d'ailleurs éviter de "jouer avec le web" pendant que tu as le montage actif au risque de "désynchroniser" le cache des répertoires.
Regarde le "man" pour les options de "rafraîchissement".

Jarodd a écrit :

Concernant mon erreur de droit sur le FTP, c'erst "normal". Trouvé dans l'aide :
Le service FTP de 1fichier.com, ne permet que le dépot de fichiers.
Vous ne pourrez donc pas télécharger des fichiers avec et/ou gerer des dossiers.
Ca s'appelle FTP mais ça ne permet pas de faire du vrai FTP...

Oui, le FTP est "write-only" amusant non !..
Tu ne peux faire que 3 choses : écrire un fichier, append sur un fichier (1fichierfs ne se sert pas de ça), ou détruire un fichier que tu viens d'écrire. Tu ne peux ni lire, ni même renommer un fichier (ce que 1fichierfs contourne !)

EDIT

Jarodd a écrit :

Sur l'interface de 1Fichier > Mes fichiers, je vois le répertoire, mais impossible d'y accéder. Est-ce que vient de la même restriction de droits ? Je pensais avoir une sorte de miroir entre le montage 1fichierfs et l'interface web.
Pour les droits, le répertoire est en 775, le fichier 555 (je suis le proprio de tout). Peut-être une incompatibilité avec les permissions/users côté 1Fichier ?
Comme tu le dis il faut que je commence par le man !
Edit : 10mn après les fichiers envoyés sur mon montage sont apparus. Donc il doit y avoir un cache ou une synchro avec un délai quelque part qui ne les fait pas apparaître immédiatement.

Oui tout est dans le man ! Donc je comprends mieux maintenant. Quand tu disais "accéder aux répertoires" c'est le vocabulaire qui est incorrect.
Si tu fais une copie d'un répertoire avec son contenu, le répertoire lui-même sera visible immédiatement sur l'interface web, et accessible immédiatement... désolé d'être pointilleux sur le vocabulaire !
Par contre oui, le répertoire ne contiendra aucun fichier puisqu'ils sont dans leur cycle de téléchargement qui est expliqué sur le man très en détail.
En gros 1fichierfs fait comme si tu envoyais les fichiers via Filezilla, et dans ce cas, c'est tout pareil, ils sont visibles sur l’arborescence web "après un certain temps" !

Si tu veux connaître les fichiers qui sont dans leur cycle d'upload (et à quel avancement) je te conseille d'activer les statistiques, ça donne une vision cool.

Et n'hésite pas à signaler un bug ou un comportement étrange ou améliorable (dans les limites des contraintes de l'infrastructure 1fichier.com !).

Dernière modification par Zakhar (Le 18/01/2021, à 22:08)

Zakhar · Le 20/01/2021, à 18:05

@Jarodd si tu fais de la sauvegarde, je te recommande, une fois les fichiers en ligne, de faire une comparaison (diff) pour t'assurer que tout est bien stocké et lisible.
diff te permet de comparer y compris des arborescences.

Pour ce qui est de la "confidentialité" des fichiers stockés, l'aide en ligne de 1fichier.com recommande elle-même le chiffrement côté client (encfs, cryptomator, ou ce que tu veux !)

1fichier.com a écrit :

Protection des fichiers
Les liens de téléchargement fournis sont privés tant que vous ne les diffusez pas.
(...)
Pour une sécurité maximale, nous recommandons le chiffrement de vos données avant leur émission.

La 1.8.2 avec le "micro-bug" corrigé est en test sur mes machines.

Dernière modification par Zakhar (Le 20/01/2021, à 18:06)

Zakhar · Le 23/01/2021, à 15:50

(23 Janvier 2021) Version 1.8.2

Nouveautés par rapport à la 1.8.1

Bug mineur : le calcul des dates de reprise était incorrect quand la date de la machine est inférieure à la date de création du répertoire de marquage, provoquant un effacement des informations de reprise.
Divers mise à jour de (c) dans le source à 2021.
Documentation le manuel a été mis à jour (la mise à jour avait été omise sur la 1.8.1).

Mise à jour : version mineure
Le bug en question se produit uniquement avec des machines comme le Raspberry Pi qui n'ont pas de pile pour converser l'heure une fois éteinte. Donc comme le Pi redémarre à l'heure qu'il avait quand il a été éteint, jusqu'à ce que l'heure soit mise à jour par NTP (avec les horloges sur internet), cela pouvait déclencher le bug corrigé ci-dessus car le test sur les dates était fait de façon incorrecte.
Si vous n'avez que des PC qui ont une pile en état de fonctionnement et donc conservent une heure à peu près exacte même éteints, le bug (corrigé) ne pouvait pas se produire.

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

$ stat -c "%s %n" 1fichierfs_1.8.2~buster-1_armhf.deb; sha256sum 1fichierfs_1.8.2~buster-1_armhf.deb; md5sum 1fichierfs_1.8.2~buster-1_armhf.deb 
83204 1fichierfs_1.8.2~buster-1_armhf.deb
d3e70760533b4b1ac823fadf2df9c466e48915f2146518b01621004f6f15a6b8  1fichierfs_1.8.2~buster-1_armhf.deb
573e987bac2303f37e60dc83c589fad5  1fichierfs_1.8.2~buster-1_armhf.deb

Jarodd · Le 27/01/2021, à 21:23

Hello
Apparemment j'ai oublié de poster mon message tapé il y a plusieurs jours. Donc je récapitule :
J'ai utilisé 1fichierfs, il fonctionne très bien ! Et j'ai bien retrouvé ensuite les fichiers déposés dans l'interface web.
J'ai une question par rapport à la doc, qui propose de mettre l'API key dans un fichier de config.
J'ai mis le mien dans ~/.config/1fichier/api.key, permissions 700. Est-ce une bonne chose ? Ou y a-t-il une meilleure "pratique" pour éviter qu'il ne passe en clair ? (et je n'aime pas taper la clé à chaque fois non plus).

Zakhar · Le 27/01/2021, à 21:59

Parfait, tu as bien lu la doc !

Ce que tu as fait est très bien, tu peux même le mettre en permission 400 puisque :
- ce n'est pas un "exécutable" !
- une fois que tu y a mis ta clé d'API, tu n'as aucune raison d'écrire à nouveau dedans (tu peux mettre 600 pour ne pas t'ennuyer si tu changes souvent ta clé d'API)

C'est la meilleure façon de faire par rapport à ce qui est disponible car effectivement, taper sa clé à chaque fois est moyennement cool (même si c'est en théorie le plus sécurisé) et mettre la clé dans la ligne de commande la révèle dans la liste des process. Là tu ne révèles que le fichier où se situe la clé, et puisqu'il t'appartient et n'est lisible par aucun autre, tout va bien !

Ça ne protège pas contre le vol de ton PC directement, à moins que tu n'aie chiffré ton répertoire /home, ce qui est une bonne pratique mais que peu de gens font (même pas moi !). Je me dis que si on en arrive à me voler mon PC... on m'aura pris pas mal de trucs, et ce n'est pas ce que j'ai sur 1fichier.com qui va intéresser !.. De toute façon ma partie "privée" sur 1fichier.com est chiffrée, et il faudrait aussi la "phrase de passe" pour récupérer.

Dernière modification par Zakhar (Le 27/01/2021, à 22:04)

Jarodd · Le 15/02/2021, à 20:02

Bonjour,
Les fichiers ne conservent pas leurs propriétés de date : c'est causé par 1fichier, ou par le script ?

Zakhar · Le 15/02/2021, à 22:01

Par 1fichier.com

La date du fichier est celle où tu l'as enregistré sur le serveur. Il n'est malheureusement rien que le driver ne puisse faire sur ça.
Il n'y a pas d'API pour "changer la date" (comme tu peux le faire avec "touch")... ce serait une "triche" un peu facile pour tromper le hot/cold !

Le driver te montre exactement la même date de tes fichiers que ce que tu peux voir sur l'interface web fourni par 1fichier.com

Donc si tu veux faire un rsync, il faut que tu le fasses seulement sur les noms et tailles des fichiers, pas sur les dates.

Aussi, 1fichier.com ne gère qu'une seule date : la date de création du fichier, contrairement à POSIX qui en gère 3 : atim, mtim, ctim, respectivement accès, modification, changement.

Donc le driver prend la date unique stockée chez 1fichier.com et la réplique dans les 3 dates POSIX.
Idem pour les répertoires, à l'exception de la racine (elle n'a pas de "date" chez 1fichier.com, ce serait en fait la date de création de ton compte !). La racine garde les mêmes dates que ton répertoire de montage.

Exemple :

stat ~/1fichier/Divers/A.TXT 
  Fichier : /home/zakhar/1fichier/Divers/A.TXT
Accès :  2019-01-16 22:01:29.024611096 +0100
Modif. : 2019-01-16 22:01:29.146907084 +0100
Changt : 2019-01-16 22:01:29.146907084 +0100

Tu remarques une tout petite différence sur les fractions de secondes parce que le driver ne prend pas de temps à les changer (et que 1fichier.com ne donne pas cette précision !), tu as toujours les valeurs qui proviennent de ton répertoire de montage pour cette "fraction".

Ce comportement est sans doute à peu près identique sur pas mal d'espaces de stockage, sinon il faudrait tenir compte des "metadata" qui sont toutes différentes d'un filesystem à un autre !..
1fichier.com ne permet pas naturellement d'enregistrer des "metadata" arbitraires (comme des dates, des attributs étendus, etc...) pour les objets stockés.

Ainsi, ce n'est pas que la date qui n'est pas conservée, mais aussi le propriétaire/groupe et les droits, puisque cette notion n'existe pas sur 1fichier.com.
Donc tous les fichiers sont à toi et dans ton groupe (sauf si tu as précisé un autre uid/gid au montage), et avec les droits hérités du répertoire de montage sauf le bit d'écriture qui est à zéro (plus un éventuel umask au montage).

On pourrait contourner cette limitation en enregistrant, sous forme codée et très limitée en longueur, des "metadata" dans la zone "description".
Cela présente cependant pas mal d'inconvénients majeurs :
- l'utilisateur peut "casser" à tout moment ce qui se trouve dans la description et remplacer par autre chose (risque sécurité/crash du programme)
- il peut tout simplement avoir besoin de la "description" pour précisément y mettre ce pour quoi ça a été fait : une description !..
- mais surtout la "description" n'est pas ramenée dans le listing général des répertoires, et il faudrait donc faire un appel d'API pour chaque fichier pour la récupérer.

Donc se lancer dans ce genre de "hack" n'est pas une bonne idée, désolé, on n'utilise que le "standard" fourni par 1fichier.com, c'est à dire une date unique, pas de notion de user/groupe ni de droits Posix !

Dernière modification par Zakhar (Le 15/02/2021, à 22:36)

Jarodd · Le 16/02/2021, à 14:36

Merci pour les précisions

Zakhar · Le 16/02/2021, à 21:30

De rien.

J'en profite pour une future bonne nouvelle. J'ai eu un échange par mail avec la team 1fichier, sans doute pour mon ancienne demande d'améliorer l'upload.

Leur plan est de mettre à disposition des clients (abonnés) une API spécifique d'upload en http qui permet la fonctionnalité : "chunked encoding". Cela permettra ainsi de laisser tomber l'upload en ftp et utiliser cette nouvelle fonction upload http réservée aux abonnés. En effet l'upload http actuel n'est guère plus qu'un habillage de l'upload qui existe pour tout le monde, mais surtout, vue la façon dont il fonctionne, il n'est pas compatible avec le "chunked encoding", ce qui ne permet pas de l'utiliser dans 1fichierfs.

Le passage à ce "nouveau http" amélioré permettra d'énormes simplifications dans le programme sur la partie écriture.
D'un point de vue utilisateur, on va gagner les "5 minutes d'attente ftp". Je n'ai pas encore vérifié, mais en principe le fichier devrait être visible tout de suite sur l'interface web une fois la copie (upload) finie, même s'il restera indisponible en lecture pour un petit moment.

Cela éviterait donc les questions que tu te posais Jarodd, en ne voyant pas les fichiers arriver tout de suite sur le web après les avoir copiés.

Accessoirement, toute la partie "reprise" va devenir inutile, ça fait un paquet de code qui va disparaître et vraiment une super simplification bienvenue.

La "team 1fichier" n'a pas donné de date pour l'amélioration, mais devrait me prévenir en "pré-test" quand ils considéreront que c'est en "bêta".

En attendant je continue à travailler sur le "nouveau moteur de stream" plus "propre" et sans doute plus rapide car ne nécessitant pas de switch de contexte (dans la plupart des cas) pour la lecture.

Dernière modification par Zakhar (Le 16/02/2021, à 21:33)

Jarodd · Le 18/02/2021, à 22:39

Bonne nouvelle !

Zakhar · Le 18/02/2021, à 23:07

Jarodd a écrit :

Bonne nouvelle !

Oui, enfin c'est sans engagement de date chez 1fichier.com, et ensuite faut que je fasse le code.

Mais bon, comme Debian, ce sera là : quand c'est prêt !..

Dernière modification par Zakhar (Le 19/02/2021, à 10:46)

Jarodd · Le 21/02/2021, à 16:28

Bonjour,
J'ai un petit souci quand j'ai le montage avec 1fichierfs : je ne peux pas écraser un fichier déjà présent. Je dois effacer l'actuel, puis relancer la copie pour le transférer.
L'erreur "permission non accordée".
Mon fichier est en -r-xr-xr-x
Le répertoire le contenant en drwxrwxr-x.
Je suis propriétaire du fichier et du répertoire.

Sur mon disque source, le fichier est en -rw-rw-r--, donc je perds la permission w pour le transfert.
C'est le système de permissions d'1fichier qui cause cette erreur ?
Ou bien comment puis-je définir le fait d'avoir le droit d'écriture par défaut ?
Actuellement c'est cela qui m'empêche d'utiliser rsync car j'ai des erreurs à chaque fois que le fichier existe (je ne copie que les nouveaux).

Merci

Zakhar · Le 21/02/2021, à 21:06

En fait les droits n'y feront rien parce que tu ne peux pas faire de l'overwrite d'un fichier, ce n'est pas possible avec 1fichier.com (et avec sans doute 99% des stockages !).

Donc en pratique, il faut effectivement commencer par effacer le fichier et le ré-écrire.

Je peux améliorer les choses en programmant le "truncate"... si toutefois rsync fonctionne bien en faisant un "truncate" à zéro, sinon c'est raté.

En fait un "truncate à zéro" est l'équivalent de :
- supprimer le fichier
- créer le fichier à nouveau à zéro

Je vais faire deux choses :
- regarder s'il existe une option rsync pour supprimer au lieu de faire "truncate"
- si rsync fait un truncate à zéro, je regarde si c'est réaliste de le rajouter...

[Edit] Bon, je vois !

En fait, par défaut, rsync fait la copie vers un fichier temporaire, puis une fois la copie faite, il fait un rename. Le rename standard écrase la destination, mais ce ce n'est pas ce que fait 1fichierfs. Par défaut, 1fichierfs se comporte comme renameat2 avec l'option NO_REPLACE, et donc renvoie une erreur "le fichier existe".

L'autre option qui existe c'est la mise à jour "inplace", mais celle-ci ne fonctionne pas car il est effectivement impossible de "modifier" un fichier existant (explication plus haut).

Donc je vais effectivement te faire une option pour que "rename" se comporte en écrasant le fichier cible s'il existe. Cela sera "non atomique", on ne peut guère faire autrement, donc en cas de plantage entre les 2 opérations, tu auras un fichier supprimé, et un fichier temporaire pas encore renommé. C'est pourquoi je n'avais pas choisi de faire de la sorte.

En attendant (comme ça va prendre un peu de temps !) tu as un contournement un peu lourd qui consiste à faire ça :

rsync -r source destination -v -n >/tmp/list.txt
rsync -r source destination -v -n --ignore-existing >/tmp/list_ign.txt
grep -F -x -v -f /tmp/list_ign.txt /tmp/list.txt

Explications :
- première ligne liste les fichiers qui seraient copiés par rsync sans faire la copie (option -n = dry-run, simule seulement)
- deuxième ligne, idem, mais saute les fichiers qui existent déjà (donc ceux qui seraient modifiés)
- troisième ligne affiche les lignes dans la deuxième liste qui ne sont pas dans la première. On va donc lister uniquement les fichiers modifiés

Cela va te donner la liste des fichiers modifié (en enlevant les deux lignes de statistiques du bas).
Tu pourras alors mettre dans un fichier, et faire une suppression globale avant le rsync qui fonctionnera puisque tu as enlevé les fichiers modifiés.

... attention à ne pas te planter, et bien supprimer les fichiers modifiés à la destination et pas à la source !

Dernière modification par Zakhar (Le 21/02/2021, à 22:03)

Zakhar · Le 22/02/2021, à 11:54

Alors la piste est la suivante.

Je vais implémenter la "dé-duplication" qui n'a jamais été mise en place.
En quoi cela consiste : en réalité 1fichier.com autorise d'avoir plusieurs fichiers qui ont exactement le même nom, puisque le nom n'est qu'un attribut comme un autre et que la véritable clé unique est l'URL du fichier.
Pour autant, le nom du fichier étant ce qui permet à l'utilisateur de désigner celui-ci sur Linux, il n'est pas judicieux de présenter plusieurs fichiers du même nom.
Aussi un fichier peut avoir le même nom qu'un répertoire sur 1fichier.com, mais on ne peut pas nommer deux répertoires de façon identique (dans le même répertoire parent). Pour fuse, si un répertoire et un fichier ont le même nom, le fichier est masqué et seul le répertoire apparaît.

La "dé-duplication" aura donc les fonctionnalités :
- cacher les fichiers qui ont le même nom qu'un répertoire
- ne garder qu'un seul des fichiers (le plus récent) quand plusieurs fichiers ont le même nom.

Une fois ceci fait, le "rename" sera modifié dans le cas où on renomme vers un fichier existant, pour fonctionner en deux étapes, puisqu'on ne peut pas le faire "atomique" comme cela serait attendu :
-1) renommer : on va alors se trouver avec 2 fichiers au nom identique
-2) supprimer l'ancien

Dans le cas de rsync, le nouveau fichier qu'on renomme est forcément plus récent, donc même si on "plante" après l'opération 1 et avant la 2, au redémarrage on affichera bien uniquement le plus récent.
Cela limite le risque dû à l'opération non-atomique.

Dans ce cas (espérons improbable) de "plantage/coupure d'électricité" au mauvais moment, ce sera charge à l'utilisateur de supprimer les anciens fichiers en doublon qui ne sont plus nécessaires, en utilisant l'interface web 1fichier.com

Le programme journalisera les cas de "doublon" pour aider l'utilisateur à "faire le ménage" si nécessaire.

[Edit] : bon, c'est codé, maintenant reste à tester.
La partie "déduplication" était facile et testée unitairement. On ne peut plus le reproduire avec l'interface web qui maintenant protège de ça.
Pour le "rename", ça fait pas mal de cas selon que le rename est un fichier en cours d'écriture ou pas et qu'il remplace un fichier en cours d'écriture ou pas (4 cas en fait !). Pour les répertoires, le rename de la sorte n'est pas possible, mais je ne pense pas que ce sera un problème avec rsync.
Donc vu les cas divers, je vais sans doute devoir enrichir le jeu de test de non régression histoire de m'assurer d'être passé partout.

Dernière modification par Zakhar (Le 22/02/2021, à 20:00)

Zakhar · Le 23/02/2021, à 22:21

@Jarodd, la version 1.8.3 incluant la dé-duplication et le rename vers fichier existant est testée unitairement avec plusieurs cas: r/r, w/w, r/w, w/r, et diverses phases de write.

La fonctionnalité soulignée ci-dessus permet de faire fonctionner rsync dans le cas des "modifications". Compte tenu du fonctionnement de 1fichierfs dû au FTP (en attendant d'avoir l'upload spécial en http promis !), ce sera vraiment visiblement "non atomique" !.. C'est à dire les fichiers modifiés apparaîtront pendant plusieurs minutes comme "supprimés" si tu regardes le compte sur le web, puis petit à petit il "ré-apparaîtront" avec leur nouveau contenu modifié. Par contre, si tu regardes via 1fichierfs, ton arborescence apparaîtra toujours cohérente par rapport aux modifications faites par rsync.

C'est poussé sur le GitLab, et donc si tu es pressé et aventureux, tu peux compiler le programme (instructions dans le post 1).

Sinon je vais enrichir les jeux de test, mettre à jour la documentation, et le garder en observation un petit moment sur mes PC avant de le packager sur le PPA.

[Edit (samedi 27 février 14:00)] tests de non régression complétés et passants. J'ai eu un crash, mais c'était en sortant du driver (fusermount -u) et je n'arrive plus à le reproduire. Il n'est sans doute pas dû aux dernières modif, et dans la mesure où c'est quand on quitte l'application, ce n'est pas trop dramatique... + Un bug mineur corrigé dans un cas particulier et améliorations du test de non régression (davantage standard pour les libellés anglais + bugfixes).
Donc je mets à jour la doc, le programme est déjà en observation sur mes PC, et si tout va bien d'ici quelques jours je package tout ça.

Dernière modification par Zakhar (Le 27/02/2021, à 21:55)

Jarodd · Le 28/02/2021, à 10:30

Salut
Ok je suis prêt à tester quand ça sera prêt (je ne sais pas compiler )
Sinon, c'est ch...t de ne plus avoir les notifications du forum. Je suis abonné au sujet pourtant.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#276 Le 11/01/2021, à 19:18

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

#277 Le 16/01/2021, à 18:50

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

#278 Le 16/01/2021, à 20:16

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

#279 Le 16/01/2021, à 21:11

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

#280 Le 16/01/2021, à 23:05

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

#281 Le 18/01/2021, à 14:04

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

#282 Le 18/01/2021, à 17:29

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

#283 Le 18/01/2021, à 18:00

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

#284 Le 18/01/2021, à 21:04

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

#285 Le 18/01/2021, à 21:24

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

#286 Le 20/01/2021, à 18:05

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

#287 Le 23/01/2021, à 15:50

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

#288 Le 27/01/2021, à 21:23

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

#289 Le 27/01/2021, à 21:59

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

#290 Le 15/02/2021, à 20:02

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

#291 Le 15/02/2021, à 22:01

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

#292 Le 16/02/2021, à 14:36

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

#293 Le 16/02/2021, à 21:30

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

#294 Le 18/02/2021, à 22:39

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

#295 Le 18/02/2021, à 23:07

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

#296 Le 21/02/2021, à 16:28

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

#297 Le 21/02/2021, à 21:06

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

#298 Le 22/02/2021, à 11:54

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

#299 Le 23/02/2021, à 22:21

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

#300 Le 28/02/2021, à 10:30

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

Pied de page des forums