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

Zakhar · Le 13/09/2024, à 23:12

Oui Z3ndra, il y a un bug connu. Les fichiers ne sont pas "corrompus" mais parfois la version actuelle se plante, et il n'y a effectivement pas d'autre solution que de tuer le process et relancer.

C'est corrigé depuis un moment chez moi, mais je n'ai pas encore eu le temps de packager, beaucoup de travail et d'activités à côté.

Le github est à jour cependant, tu peux compiler la dernière version corrigée depuis celui-ci. Comme je rentre, en plus du travail, dans un période de travaux au domicile de ma mère, je ne suis pas sûr d'avoir le temps de faire la package de si tôt hélas.

Mais je note ta demande, comme jusqu'à présent personne n'avait rien dit je présumais que ça ne gênait pas, et je vais monter la priorité de cette tâche.

Aussi, il va falloir que je rajoute la version packagée pour 24.04 en espérant que le tuto antique que j'ai suivi y fonctionne toujours !

Dernière modification par Zakhar (Le 13/09/2024, à 23:15)

z3ndra · Le 22/09/2024, à 13:12

Ca marche merci pour ta réponse, je vais plutot attendre la version packagée ça sera plus simple. Vraiment hate. Apres en attendant j’ai mit un script qui verifie l’accessibilité d’un fichier toute les 10 min et si il est inaccessible parce que ça a planté, ca le demonte et le remonté automatiquement mais ça reste relou lol

z3ndra · Le 26/09/2024, à 12:06

salut, j'ai aussi remarqué un truc , c'est que 1fichierfs se met a consommer enormement de ressources cpu, ce qui freeze le serveur à la longue.

Zakhar · Le 09/10/2024, à 23:25

Oui @z3ndra !
Ça fait partie du bug connu. Quand le bug se produit, ça peut planter, mais aussi les requêtes peuvent se mettre à tourner sans fin entre les threads, et du coup ce n'est pas planté, mais le fichier qui était lu est bloqué, et le CPU monte en flèche à cause du passage en boucle sans fin entre threads. Dans ce cas là : kill + fusermount -u

Il est possible que l'option -o sync_read fasse disparaître le bug puisqu'il se produit quand on a plusieurs requêtes en parallèle a début d'un fichier, mais cela peut aussi avoir un impact sur la performance... à tester donc !

Je viens de faire le dernier test qui nécessite de changer un paramètre interne pour forcer certaines choses à se produire, et ça fonctionne comme prévu.
J'ai "taggé" la version 1.9.5 sur le gitlab, elle est prête pour la release.

Je vais mettre à profit la grippe/arrêt de travail pour tâcher de vous packager cette 1.9.5 qui corrige ces méchants bugs de synchro.
Aussi elle apporte la "log circulaire" que j'ai mise en place précisément pour attraper ce bug de boucle infini. La log étant vite pleine en mode debug, je n'avais pas la "fin". Avec le système circulaire, si on tue le programme suffisamment vite quand la boucle infinie se produit, on peut avoir l'instant qui a déclenché la boucle-bug.

Aussi il va falloir que je songe à 2 trucs pour le futur :
- déprécier la 16.04, en effet elle oblige à maintenir des paramètres de compilation spécifiques (gnutls au lieu de openssl)
- regarder fuse 3 qui est le fonctionnement par défaut au moins sur la 24.04 (et peut-être déjà en 22.04 !). Fuse 2 est toujours supporté bien sûr... heureusement !

Dernière modification par Zakhar (Le 10/10/2024, à 00:01)

Zakhar · Le 10/10/2024, à 16:40

(10 octobre 2024) Version 1.9.5

Nouveautés par rapport à la 1.9.4

Fix bugs/crashes : crash ou boucle infinie (avec forte consommation de CPU) lors d'inversion des premières requêtes de lecture d'un fichier.
Fix bugs/crashes : crash/bug théorique quand un fichier est abandonné (time out interne) et au même moment rouvert.
Nouvelle LTS : le logiciel est désormais également packagé pour la dernière LTS : Noble Numbat - 24.04.
Fonctionnalité : possibilité de limiter la taille du fichier journal, lequel devient alors un journal "circulaire" (mode debug uniquement).
Documentation : mise à jour de la documentation en 1.9.5.

Mise à jour
Le crash ou boucle constaté a d'autant plus de chance de se produire qu'on ouvre beaucoup de fichiers.
Même si vous ne l'avez jamais constaté, il est plus prudent de faire la mise à jour.

A noter que le package standard ne comportant pas la fonctionnalité "DEBUG", vous n'avez pas la nouvelle fonctionnalité "journal circulaire" puisque elle n'est vraiment nécessaire que dans ce mode là. Cette fonctionnalité, si vous la souhaitez, nécessite donc que vous compiliez vous-même le package depuis le gitlab, et que vous lanciez le driver en mode verbosité 7 (--log-level 7)
L'aide (1fichierfs -h) n'indiquera pas la nouvelle fonctionnalité puisqu'elle n'est pas disponible hors DEBUG, par conte le "man" vous l'expliquera avec cette limitation.

Pistes futures (sans urgence) :
- Déprécier 16.04 et 18.04 qui nécessitent une fabrication particulière avec gnutls au lieu de openssl
- Regarder les nouvelles fonctionnalités de Fuse 3. Si elles présentent un intérêt pour 1fichierfs, les implémenter. En effet, en 24.04 Fuse 3 est le standard au lieu de Fuse 2 (toujours supporté)
- Améliorations diverses.

Pour Raspberry Pi, je vais désormais fournir le package 64 bits Bookworm. Pour Buster 32 bits, vous pouvez compiler depuis le source.

Raspberry Pi OS (Bookworm 64 bits): 1fichierfs_1.9.5~bookworm-1_arm64.deb

stat -c "%s %n" 1fichierfs_1.9.5~bookworm-1_arm64.deb; sha256sum 1fichierfs_1.9.5~bookworm-1_arm64.deb; md5sum 1fichierfs_1.9.5~bookworm-1_arm64.deb 
103404 1fichierfs_1.9.5~bookworm-1_arm64.deb
0d0efc83bd6957983764f5aa894c7152daebfaea7fe57b39add628972bbfe5bd  1fichierfs_1.9.5~bookworm-1_arm64.deb
b588cb71a14e81012257531109b82f17  1fichierfs_1.9.5~bookworm-1_arm64.deb

Dernière modification par Zakhar (Le 11/10/2024, à 08:52)

Zakhar · Le 10/10/2024, à 23:53

z3ndra a écrit :

salut, j'ai aussi remarqué un truc , c'est que 1fichierfs se met a consommer enormement de ressources cpu, ce qui freeze le serveur à la longue.

La nouvelle version devrait améliorer tout ça. N'oublie pas, après la mise à jour en 1.9.5 de faire un fusermount -u si le stockage distant était monté avant la mise à jour, puis monter à nouveau le stockage distant pour que la nouvelle version soit prise en compte.

Si tu vois d'autres bugs, n'hésite pas à prévenir, chez moi ça tourne sans aucune anomalie sur mon PC principal et mon Raspberry Pi depuis au moins 1 mois.

Dernière modification par Zakhar (Le 11/10/2024, à 08:53)

Zakhar · Le 24/10/2024, à 10:20

Dans les améliorations diverses, j'en ai 2 en tête :
- Permettre un téléchargement via Firefox directement sur le montage. Après examen, il semble que parfois firefox ferme le fichier local puis le réouvre pour continuer le téléchargement. Le mode "append" n'étant pas prévu pour le moment, cela échoue.
- Permettre à encfs de renommer un fichier. En effet, le renommage sur encfs provoque le changement de 8 octets en tête du fichier qui contient en gros la clé permettant de déchiffrer. Comme l'overwrite est interdit, cela ne fonctionne pas. J'ai en tête une "astuce" pour que cela soit possible dans la majorité des cas si un sous-répertoire est déclaré géré par encfs.

Dernière modification par Zakhar (Le 24/10/2024, à 15:17)

Zakhar · Le 19/01/2025, à 17:01

La modification pour encfs est faite.
Au passage correction d'un bug sur le "retry", et diverses améliorations de journalisation, et du test de non-regression qui ne testait pas vraiment le mode http (no ssl).

C'est en test sur mes machines, je rajoute quelques cas sur les tests de non-regression, et quand tout est OK un package.

C'est sans intérêt fondamental, sauf les bugs mineurs corrigés, si vous n'utilisez pas encfs par dessus le montage 1fichierfs.

Zakhar · Le 24/01/2025, à 19:06

En rajoutant la fonctionnalité encfs, j'ai découvert un bug sur la partie "write".

On peut le recréer de la sorte, créer un fichier de 4096 caractères ne contenant que des A, puis un fichier de 1024 ne contenant que des B :

$ printf "A%.0s" {1..4096} >fileA
$ printf "A%.0s" {1..1024} >fileB

Ensuite lancer la commande suivante sur votre montage :

$ cp fileA ~/1fichier/Divers/Test/file; dd if=fileB of=~/1fichier/Divers/Test/file bs=1024 count=1 conv=notrunc

-1) les deux commandes enchaînées vont (sans doute) fonctionner... alors que la seconde devrait échouer, la documentation précisant qu'on ne peut pas ré-écrire sur un fichier existant.
-2) On s'attend à avoir en résultat un fichier avec 1024 B au début puis le reste avec des A. C'est peut-être ce que vous verrez avec la cache du kernel, mais si vous "droppez" les caches, vous verrez en fait le fichier plein de A
-3) Une fois le cycle d'upload terminé (et éventuellement en "droppant" les caches), vous verrez (sans doute) le fichier attendu.

En réalité c'est peu fiable et ça peut créer des corruptions de fichiers parce que comme ce n'était pas prévu, l'écriture n'est pas "verrouillée" et on peut donc écrire des bouts d'un fichiers ou de l'autre.

La correction est faite. Le fonctionnement tel que décrit ci-dessus est pérennisé mais géré de façon "propre" c'est à dire avec le verrouillage adéquat. Cela permet notamment, quand on fait un rsync avec des petits fichiers (moins de 64K) sur une arborescence gérée par encfs, de ne pas avoir le "hack de renommage" sur ces fichiers là, ou au moins de tâcher de le limiter.

La test sur mes PC va donc prendre un peu plus de temps. En attendant, évitez les commandes comme celles montrées ci-dessus. Si vous ne faites que des écritures simples, comme par exemple une copie de fichier vers votre stockage, vous ne rentrez pas dans le cas de bug.

Dernière modification par Zakhar (Le 24/01/2025, à 19:07)

Zakhar · Le 23/02/2025, à 00:57

Encore un peu de patience !
1fichierfs s'étant planté au bout de plus de 15 jours d'usage quotidien sur mon Raspberry Pi, je vois un bug rare sur la fonction qui affecte les lectures aux "streams" (read_fits_stream). Il se produit quand un stream a un "gap" et reçoit une requête retardée et répétée pendant qu'il lit la suite.

Comme c'est une fonction centrale de l'algorithme, je vais tâcher de corriger avant de livrer les évolutions !
C'est aussi délicat à tester car le cas de bug se produit de façon très exceptionnelle et il n'y a aucune façon fiable de reproduire la séquence de lecture exacte qui provoque le bug rencontré.

En effet, en principe le kernel cachant les lectures ne répète pas les mêmes blocs de 4096. Cela peut bien sûr se produire en cas de pression sur la mémoire si une cache a dû être relâchée et qu'on a encore besoin des blocs antérieurs. Bref, cas rarissime mais pas inexistant, donc il faut tout de même corriger !

Dernière modification par Zakhar (Le 23/02/2025, à 01:06)

favancini · Le 07/07/2025, à 18:07

Salut,

Merci pour ton travail.

J'ai installé le logiciel sur un pc sous Ubuntu et j'ai pu monté mon stockage 1fichier très facilement.

Je voudrais utiliser ton logiciel sur mon NAS Qnap avec un cpu Intel x86

J'ai téléchargé "astreamfs-1.9.5.zip" depuis Gitlab

J'ai réglé plusieurs problèmes de dépendances et ensuite j'ai le message :

1fichier: line 219: astreamfs: command not found

Je ne sais pas comment régler le problème

Merci pour votre aide

Dernière modification par favancini (Le 07/07/2025, à 19:15)

Zakhar · Le 21/08/2025, à 13:14

Bonjour favanchi,

Dans le Gitlab il y a 3 logiciels en fait.
- astreamfs (exécutable)
- 1fichierfs (exécutable)
- 1fichier (script)

1fichierfs, comme son nom l'indique, sert à monter simplement ton stockage 1fichier.com
astreamfs est un programme générique qui peut monter n'importe quelles URL http/https, à partir du moment où le serveur sert des "range". Bien sûr, contrairement à 1fichierfs, astreamfs ne fait que de la lecture, et pour créer l'arborescence, il faut que tu la passes en paramètres du programme.
1fichier (le script) est l'ancienne façon de monter ton stockage distant 1fichier.com. Il utilise astreamfs comme outil de lecture et il crée une ligne de commande complexe qui restitue l'arborescence de ton stockage. Le montage reste alors pour de la lecture seule puisque le script utilise l'exécutable astreamfs.

Donc le message d'erreur que tu as là, c'est parce que tu essayes d'utiliser l'ancienne façon de monter le stockage distant via le script.
Tu n'as sans doute pas compilé astreamfs, donc ça ne peut pas marcher !..

C'est (sans doute) toujours possible d'utiliser cette ancienne façon de monter ton cloud 1fichier, bien que je ne l'aie pas testé depuis des lustres, mais je ne le recommande pas.

En fait il faut que tu utilises plutôt 1fichierfs (l'exécutable) si tu as réussi à trouver les deux dépendances nécessaires par rapport à ton NAS : curl-dev et fuse-dev.

La commande doit donc plutôt être 1fichierfs et non pas 1fichier qui lance le script !

(Et désolé pour la réponse tardive, je n'ai pas eu le mail d'alerte de réponse sur le fil que je suis !)

Dernière modification par Zakhar (Le 21/08/2025, à 13:26)

Jarodd · Le 26/08/2025, à 20:25

Bonjour,
J'ai réinstallé 1fichierfs, à la tentative de montage j'obtiens :

$ 1fichierfs /media/jarodd/1fichier --api-key=monid
[1fichierfs     0.104] ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/folder/ls.cgi` name=`/`.

Que dois-je faire svp ?

Zakhar · Le 27/08/2025, à 23:26

C'est assez parlant. 403 veut dire accès refusé.

Donc le serveur ne veut pas que tu utilises l'API... ce qui empêche en quelque sorte tout fonctionnement de 1fichierfs. En effet, pour commencer, et vérifier que cela fonctionne, la première chose que fait 1fichierfs est de lister (ls) la racine de ton montage. Si cela ne fonctionne pas (ce qui est le cas ici), le montage n'est pas créé, et le programme se termine

Pourquoi est-ce que cela arrive... il peut y avoir de multiples raisons allant du bannissement temporaire (trop d'erreurs 403 peuvent provoquer cela) au fait par exemple que tu aies verrouillé les IP qui peuvent accéder à ton compte dans l'interface web standard 1fichier.com, ou aussi potentiellement ta clé d'API est mauvaise... au pire une IP bannie définitivement !

Par exemple, est-ce que tu as accès à ton compte depuis cette machine sr l'interface web standard ?

Pour l'accès à l'API, tu peux essayer l'exemple donné dans la documentation API de 1fichier.com pour lister les fichiers qui se trouvent à la racine :

$ curl -H "Authorization: Bearer $( cat ~/.1fichier.key)" -H "Content-Type: application/json" -X POST -i https://api.1fichier.com/v1/file/ls.cgi -d '{"folder_id":0,"pretty":1}'
HTTP/2 200 
server: nginx
date: Wed, 27 Aug 2025 21:29:44 GMT
content-type: application/json; charset=utf-8
vary: Accept-Encoding

{
   "status" : "OK",
   "count" : "0",
   "items" : []
}

Le retour est normal, observe bien le code retour 200. Le fait qu'il n'y ait pas de fichiers listés est aussi normal : je n'ai aucun fichier à la racine, uniquement des répertoires. Le retour dit bien cela : zéro fichier, le status est bien "OK" dans le JSON.

L'exemple ci-dessus fonctionne avec la clé d'API dans le fichier ~/.1fichier.key
Si ce n'est pas ta façon de faire, tu remplace simplement l'expression $( cat ~/.1fichier.key) dans les "double quotes" au début de la commande par ta clé d'API.
L'avantage de faire comme je le fais ici est le confidentialité : je peux poster la commande sans révéler ma clé d'API, et ce qui est enregistré dans .bash_history ne comporte pas non plus ma clé d'API.
Pour 1fichierfs, tu peux aussi faire de même en passant la clé ainsi : --api-key=@/home/zakhar/.1fichier.key
Le fait que ce qui suit l'argument --api-key commence par un @ indique à 1fichierfs qu'il s'agit en fait d'un fichier qui contient ta clé d'API.
Autre avantage, si tu veux regénérer ta clé d'API, il suffit de la remplacer dans le fichier, pas besoin de changer tes commandes.

Donc pour résumer, si la commande curl ci-dessus te rapporte un code erreur 403, ce n'est pas un bug de 1fichierfs, c'est un blocage du serveur.

Dernière modification par Zakhar (Le 27/08/2025, à 23:44)

Zakhar · Le 27/08/2025, à 23:55

Sinon, je continue bien sûr de travailler (à temps libre) à mon programme.
Actuellement j'ai un bug d'écriture sur la pile encfs/1fichierfs en 24.04. Le bug est (hélas) aléatoire, mais semble relativement fréquent pour que je puisse tenter de debugger.

Cela peut venir de 1fichierfs, mais tout aussi bien de encfs ou même du kernel/fuse (hélas également). Pour ces deux dernières hypothèses, le debug va être plus coton !..

En tout cas ce bug pointe aussi vers un potentiel trou de sécurité (criticité faible)
Un programme mal intentionné pourrait tenter de révéler ce qui a été écrit par un autre programme en faisant du "sparse write", c'est à dire précisément en l'état du code, écrire 1 octet à la position zéro, puis 1 octet à la position 128K - 1... et rien entre les deux écritures.
Dans ce cas, le programme va écrire, entre les deux octets ci-dessus... ce qu'il y a dans le buffer. Donc soit zéro ou ce que le kernel a laissé dans un bloc malloc (première écriture), soit des octets appartenant à un fichier précédent (écritures suivantes).

En réalité la partie "write" ne supporte pour l'instant pas cela, le "sparse write". Donc pour éviter de révéler des parties d'un autre fichier ou de la mémoire du kernel, je vais simplement renvoyer une erreur si une application fait du "sparse write".

Si quelqu'un en a besoin un jour, je verrai si ça n'est pas trop déraisonnable de l'implémenter proprement, en mettant bien des zéros dans les trous, puisque de toute façon le stockage distant ne supportant pas le "sparse write", on ne peut que faire ainsi.

Je verrai alors si le bug constaté viens d'un cas de "sparse write" (mais je doute !)... ou s'il faut vraiment debugger "niveau kernel" !..

Dernière modification par Zakhar (Le 27/08/2025, à 23:59)

Jarodd · Le 28/08/2025, à 08:31

Bonjour,
Je peux uploader un fichier depuis l'interface 1F.
Mon compte a été créé il y a quelques jours, je ne l'ai pas encore utilisé. Je suis en vacances donc l'IP est inconnue pour 1F, je ne vois pas de raison d'un bannissement.

Mon API est bien dans le même fichier :

$ cat ~/.1fichier.key 
3V33Q...xhjX

La commande de test me retourne ceci :

$ curl -H "Authorization: Bearer $( cat ~/.1fichier.key)" -H "Content-Type: application/json" -X POST -i https://api.1fichier.com/v1/file/ls.cgi -d '{"folder_id":0,"pretty":1}'
HTTP/2 403 
server: nginx
date: Thu, 28 Aug 2025 06:28:59 GMT
content-type: application/json; charset=utf-8
vary: Accept-Encoding

{
   "message" : "No such device #96",
   "status" : "KO"
}

Pour l'accès à l'API, tu peux essayer l'exemple donné dans la documentation API de 1fichier.com pour lister les fichiers qui se trouvent à la racine

Pour la doc le 1er me renvoie ceci :

$ curl -H "Content-Type: application/json" -X POST https://api.1fichier.com/v1/upload/get_upload_server.cgi -d '{"pretty":1}'
{
   "id" : "7JfVRMKvMa",
   "url" : "ru-3.1fichier.com"
}

Mon API est tiré de cet écran avec le qr code :
qr code
Ce n'est pas ansi qu'il faut faire ? (c'est une ancienne valeur ici, dès que je retourne sur cet écran j'ai une nouvelle valeur)

Edit2 : je pense avoir compris. Je note la valeur dans .1fichier.key, mais elle n'est pas enregistrée côté 1F, d'où l'erreur "No such device #96". Je ne sais pas comment le faire, il n'y a pas de bouton Enregistrer ou Valider la clé dans la section "Équipement reliés"...

Dernière modification par Jarodd (Le 28/08/2025, à 09:10)

Zakhar · Le 28/08/2025, à 09:24

Voilà, c'est bien cohérent, tu as aussi 403 avec curl.

get_upload_server n'est pas significatif, car il ne nécessite aucune clé d'API. Ce n'est pas utilisé par 1fichierfs parce que non compatible avec un fonctionnement "fuse" qui ne peut pas savoir à l'avance la taille du fichier à uploader. 1fichierfs utilise alors à la place le mode d'upload via FTP.

Oui, pour la clé d'API, ça se passe dans le menu "Paramètres" de ton compte. Il faut activer l'API, cela va te donner la clé d'API que tu dois copier/coller dans le fichier (ou mettre dans ta commande, mais elle va alors être copié dans .bash_history, sauf à précéder la commande par un espace). Ensuite la clé d'API n'est plus visible sur l'interface web, mais 1fichier.com l'a notée et associée à ton compte. Il faut donc de toute façon que tu notes ta clé d'API quelque part pour les connexions suivantes, d'où l'idée de la mettre dans un fichier !
Si tu venais à la perdre, ou si tu penses que ta clé d'API est compromise, pour la changer il faut désactiver l'API puis la réactiver pour obtenir une nouvelle clé.

Si c'est un nouveau compte, c'est bien sûr une clé d'API différente de celle que tu avais précédemment.

Tu peux aussi limiter l'API à certaines adresses IP. Comme je suis chez Free avec IP fixe, je l'ai fait ainsi en inscrivant les IPV6 et V4 de ma box. Si c'est pour un usage sur un PC portable que tu vas brancher en Wifi à plusieurs endroits, c'est bien sûr inapproprié de limité les IP de connexion. Si tu le faisais, en dehors de IP autorisées sur la page Paramètres/Clé d'API, tu aurais effectivement un retour 403 sur les IP non listées.

La partie "device", je ne sais pas à quoi cela correspond. Peut-être 1fichier.com a-t-il fait une "appli" qui fonctionne à l'aide d'une clé d'API que tu récupères via le QRCode... aucune idée je n'ai pas de smartphone (intentionnellement !)

Désolé de ne pas pouvoir t'aider davantage pour l'initialisation de la clé d'API, tout cela dépend de l'interface déployé par 1fichier.com sur leur site web, et tout peut changer sans préavis et sans mode d'emploi détaillé !..

Dernière modification par Zakhar (Le 28/08/2025, à 09:33)

Jarodd · Le 28/08/2025, à 11:13

J'ai désactivé et réactivé l'API. Et cette fois, j'ai eu un message différent, que je n'avais pas eu hier :

API Activée !
Votre clé API est xxx
Cette clé est confidentielle, doit etre stockée de maniere sécurisée et ne doit pas etre communiquée.

Avec la nouvelle clé, j'ai pu faire le montage avec 1fichierfs Merci pour le support.

Zakhar · Le 28/08/2025, à 11:29

Pas de problème. curl permet toujours de s'assurer de ce qui ne va pas quand on a un doute.

Jarodd · Le 03/09/2025, à 21:27

Bonjour,
J'ai envoyé des fichiers sur mon compte via 1fichierfs. Transferts rapides, pas d'erreur. J'ai fait un diff entre /home/jarodd/data et /media/jarodd/1fichier/data, tout est identique.
Pourtant dans l'interface 1F, j'ai juste 2 répertoires, et 0 fichier. Donc je me demande si cela a été correctement envoyé. Y a-t-il un cache et l'envoi est en cours ? Comment puis-je m'en assurer ?

Zakhar · Le 04/09/2025, à 10:23

Saleté de temporisation trop courte... j'avais écrit tout un long message, puis j'ai eu envie d'aller aux toilettes, et ça m'a tout "bouffé" !..

Lis le man :

man 1fichierfs

Tout le cycle d'écriture y est expliqué en détail.

Pour comparer valablement il faut :
- écrire ton fichier (cp, ou via l'interface graphique)
- quand ceci est fini attendre "un certain temps" (voir le man) [Ca peut monter à 30 minutes pour un fichier de 50GB, ou même plus si tu enchaînes les écritures !]
- droppper les caches (sinon tu vas potentiellement comparer des choses qui sont en mémoire de ton PC, "les caches" et donc pas totalement le fichier stocké à distance), j'utilise la commande :

free -wh; sync; echo 3 | sudo tee /proc/sys/vm/drop_caches; free -wh

- faire ton diff

A noter que "les caches" ne sont pas une invention personnelle mais un processus important du kernel pour avoir un système fluide !.. Donc un diff valable doit toujours s'assurer qu'on n'a rien "en cache", sinon on ne va pas comparer réellement ce qui est sur les supports physiques (ou à distance pour 1fichierfs ou autre stockage distant).

Si tu as le retour "Périphérique occupé", c'est que tu n'as pas attendu assez longtemps !
L'affichage des statistiques peut t'aider à savoir combien attendre parce que tu vois dans quelle "phase" se trouvent tes écritures, mais la dernière phase est purement côté serveur et donc le fichier semble bien là, mais n'est toujours pas lisible (antivirus ou autre traitement côté serveur rendant le fichier indisponible).

C'est aussi expliqué dans le "man" (ou brièvement dans l'aide) comment activer les statistiques.

Et oui, lorsque tu as commencé à écrire via 1fichiefs, celui-ci a créé automatiquement 2 choses :
- un répertoire .upload.1fichierfs qui sert de cible temporaire aux écritures
- un sous-compte 1fichierfs-UUID (UUID est variable) qui pointe vers .upload.1fichierfs et dont le mot de passe est ta clé d'API (1fichierfs ne connaît pas le mot de passe de ton compte, et c'est très bien ainsi, donc il ne peut utiliser que la clé d'API en tant que secret).

Si tu n'as plus besoin d'écrire via 1fichierfs tu peux supprimer ces deux éléments : le répertoire, et le sous compte FTP (dans l'interface standard web 1fichier.com, ça se trouve dans "Gestion FTP").
Si tu changes d'avis dans le futur et que tu te mets à écrire à nouveau via 1fichierfs, les deux éléments seront créés à nouveau automatiquement (le UUID du compte FTP aura alors changé).

Dernière modification par Zakhar (Le 04/09/2025, à 10:36)

Jarodd · Le 04/09/2025, à 12:44

Je fais mes synchros avec rsync (ou GUI équivalent). Je ne devrais donc pas l'utiliser, mais passer par cp et transférer mes fichiers un par un ? En attendant entre 2 transferts ?

Dans .upload.1fichierfs, j'ai 9 répertoires pour 6.47 Mo au total. J'ai transféré bien plus que ça. Ces nombres correspondent à ce que j'ai réellement uploadé ? Le reste s'est donc "perdu" car les transferts étaient trop rapides ?

Zakhar · Le 04/09/2025, à 19:25

Non, non, rien ne se perd... ou alors c'est un bug !
Le rsync de petits fichiers est tout à fait possible. Il te faudra juste attendre un bon moment avant de vérifier que tout va bien.
Cependant, compte tenu qu'on ne peut pas forcer la date du stockage, il faut faire fonctionner rsync en mode "checksum", ce qui prend un peu plus de temps car il commence par faire un checksum de tous les fichiers distants, puis de tous les fichiers locaux, et transfère la différence.
Egalement, il ne faut pas demander à rsync d'utiliser son algorithme pour transférer les deltas sur les fichiers car ça ne fonctionne pas avec le "cloud" qui ne permet qu'une écriture séquentielle d'un fichier en entier.

L'avantage du rsync avec checksum, d'un autre côté : c'est en quelque sorte une vérification automatique que tout a été bien sauvegardé la deuxième fois que tu le passes.
Bien sûr, pense bien à "dropper les caches" comme expliqué plus haut, sinon ça va aller très vite et juste faire le checksum des caches en RAM et non pas réellement des fichiers stockés.

Au bout d'un certain temps (24h) tu peux retirer tout ce qui est dans le répertoire .upload.1fichier, la reprise n'aura plus lieu. Normalement 1fichierfs va faire le ménage sur les répertoires (marqueurs) mais il va laisser les fichiers s'il y a eu des transferts partiels et que tu en as besoin. Cela peut arriver si par exemple il y a un crash ou si, simplement, tu éteins ta machine au milieu d'un transfert.

Si je retrouve ma commande de rsync je te la mets !

Dernière modification par Zakhar (Le 04/09/2025, à 19:26)

Zakhar · Le 04/09/2025, à 20:24

Comment faire un rsync avec 1fichierfs.

A titre d'exemple, je sauvegarde un répertoire local qui se trouve dans /home/myself/Perso
La cible est /home/myself/1fichier/Perso

L'arborescence du répertoire à sauvegarder contient 479 fichiers et 28 répertoires pour une taille cumulée de 1.1G

$ find . -type f | wc -l
479
$ find . -type d | wc -l
28
$ du  -s
1126496	.

(Nota, la taille retournée par du est par défaut en K, donc ça fait bien 1 112 496K soit environ 1,1G)

Commande utilisée :

$ rsync -cWvrn --delete  /home/myself/Perso/ /home/myself/1fichier/Perso/

Explications :
-c pour fonctionner en mode "checksum" et non pas basé sur les dates/tailles.
-W pour ne pas utiliser l'algorithme de delta. Notez que cela n'est utilisé que si vous avez des modifications de fichier, pas si la cible n'existe pas puisque alors le delta est bien tout le fichier !
-v verbeux, pour avoir l'affichage de ce qu'il va faire !
-r récursif (à moins que vous ne vouliez sauvegarder qu'un répertoire sans les sous-répertoires.
-n IMPORTANT, je commence toujours ainsi. rsync ne va RIEN sauvegarder/supprimer, mais juste vous dire ce qu'il va ferait s'il tournait vraiment. Ca permet de vérifier qu'on ne va pas tout casser, par exemple en inversant source/cible !

--delete : ça c'est si vous voulez répercuter les suppressions de votre répertoire local vers la cible. Si vous voulez aussi garder les anciennes choses sur la sauvegarde, n'utilisez pas l'option.

On fait tourner cela, ça va prendre du temps parce que rsync va provoquer la lecture de TOUS vos fichiers à sauvegarder locaux puis distants.
Si vous avez beaucoup de fichiers, il vaut mieux utiliser "l'identification réseau" pour éviter de planter au milieu, voir ça sur vos paramètres sur vote compte 1fichier.com

Une fois que vous avez vérifier que rsync va bien faire ce que vous voulez, vous relancez la commande dans le -n pour vraiment appliquer les modifications.

Cela devrait aller plus vite grâce à la "cache" (du kernel), si la taille des fichiers à lire est "raisonnable" et tient dans la RAM de votre PC. En l'occurrence 2 fois 1,1G pour moi, c'est sans problème. Sinon rsync va simplement refaire les checksums !

Cette fois les modifications seront appliquées : copie et suppressions si vous l'avez demandé.

Ensuite il faut attendre "un certain temps". Si vous avez mis les statistiques, au moins jusqu'à ce que vous ne voyiez plus aucun fichier dans la liste des fichiers dans le cycle d'écriture.

Une fois tout le cycle terminé pour tous les fichiers écrits, cette fois il faut "dropper les caches" pour correctement vérifier la sauvegarde.
Ma commande :

free -wh; sync; echo 3 | sudo tee /proc/sys/vm/drop_caches; free -wh

Et là vous refaites la sauvegarde ci-dessus avec le -n, juste pour vérifier.
Cela devrait prendre "un certain temps", dépendant du nombre de fichiers et leurs tailles et vous devriez avoir ça :

$ rsync -cWvrn --delete  /home/myself/Perso/ /home/myself/1fichier/Perso/
sending incremental file list

sent 26,249 bytes  received 39 bytes  70.95 bytes/sec
total size is 1,152,429,861  speedup is 43,838.63 (DRY RUN)

C'est à dire que la liste de choses à faire par rsync est VIDE, et vous avez confirmation de la taille (total size).

P.S.: avec la nouvelle version (pas encore publiée) ça fonctionne aussi sous encfs, parce que désormais le renommage y est possible. C'est plus pratique pour chiffrer ses sauvegardes que de le faire en local et transférer le chiffré !

Dernière modification par Zakhar (Le 04/09/2025, à 20:31)

Zakhar · Le 04/09/2025, à 20:35

Voila, je t'ai mis un "tuto" pour sauvegarder avec rsync et vérifier que la sauvegarde est correcte.

Si tu utilises un "frontend graphique" à rsync, il faut trouver l'équivalent des options présentées ici.
Les options importantes sont "checksum" (-c) et "Whole" (-W), sans quoi ça risque de planter ou de resauvegarder tout à chaque fois.

L'option -n (dry-run) couplée avec -v (verbeux) est importante pour vérifier ce que rsync va faire avant qu'il en fasse réellement son travail (éviter les erreurs).

L'option --delete, c'est selon ce que tu souhaites faire !

Après, je comprends que tu as un nouveau compte et que tu fais des "sauvegardes", donc si tu pars d'un état où le stockage cloud est vide, faire un cp (en commande ou à la souris depuis "Fichiers") ou faire un rsync revient au même.
Le cp (personnellement j'utilise pv pour avoir une jauge de progression) est plus "simple" pour 1fichierfs, juste pour un détail c'est que rsync va copier vers un fichier avec un nom temporaire, et quand la copie est faite, il renomme le fichier vers son nom cible. Ce renommage avant que le fichier soit visible est bel et bien capturé par 1fichierfs pour faire ce qu'il faut, mais ça introduit de la complexité (donc davantage de risque de bug/problème !).

Donc pour une "sauvegarde initiale", je te conseille plutôt une simple copie.

Au niveau temps de sauvegarde, ça ne change strictement rien. Les cycles d'écritures seront les mêmes dans les deux cas, avec la complexité en moins du renommage pour la "copie simple".

Rsync commence à être utile à partir du moment où tu as déjà des choses sur ton cloud et ou tu veux copier uniquement ce qui est nouveau. Cependant, le fait de devoir fonctionner avec checksum en réduit l'utilité si la sauvegarde est volumineuse, parce que la durée du checksum sur des 10aines de Go, c'est fatalement long !..

Dernière modification par Zakhar (Le 04/09/2025, à 23:09)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#501 Le 13/09/2024, à 23:12

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

#502 Le 22/09/2024, à 13:12

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

#503 Le 26/09/2024, à 12:06

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

#504 Le 09/10/2024, à 23:25

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

#505 Le 10/10/2024, à 16:40

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

#506 Le 10/10/2024, à 23:53

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

#507 Le 24/10/2024, à 10:20

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

#508 Le 19/01/2025, à 17:01

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

#509 Le 24/01/2025, à 19:06

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

#510 Le 23/02/2025, à 00:57

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

#511 Le 07/07/2025, à 18:07

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

#512 Le 21/08/2025, à 13:14

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

#513 Le 26/08/2025, à 20:25

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

#514 Le 27/08/2025, à 23:26

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

#515 Le 27/08/2025, à 23:55

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

#516 Le 28/08/2025, à 08:31

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

#517 Le 28/08/2025, à 09:24

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

#518 Le 28/08/2025, à 11:13

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

#519 Le 28/08/2025, à 11:29

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

#520 Le 03/09/2025, à 21:27

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

#521 Le 04/09/2025, à 10:23

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

#522 Le 04/09/2025, à 12:44

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

#523 Le 04/09/2025, à 19:25

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

#524 Le 04/09/2025, à 20:24

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

#525 Le 04/09/2025, à 20:35

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

Pied de page des forums