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

Zakhar · Le 22/10/2025, à 20:02

Jarodd a écrit :

Aujourd'hui, j'ai passé le journée à envoyer du contenu (~600 Go). Et de nouveau rien n'apparaît dans l'interface 1F. C'est juste un constat, je n'ai rien analysé pour l'instant.

C'est ballot !
Peut-être ce qui pourra te donner une idée de ce qui ne va pas, c'est de rajouter les statistiques et d'observer.

-1) Rajouter à la commande : --stat-file=.stats

Cela crée un fichier virtuel à la racine du montage nommé .stats (ou ce que tu veux d'autre, il suffit de le préciser dans l'option)

2) Observer les statistiques. J'utilise la commande :

$ watch -n3 cat ~/1fichier/.stats

L'idée est donc d'afficher toutes les 3 secondes (le -n 3 dans le watch) le contenu du fichier virtuel .stats à la racine du montage qui contient les statistiques du driver.

Si tu vois des erreurs... ça te donnera une idée en plus du journal niveau 6

EDIT : le seul truc auquel je pense, sans autre élément que "ça marche pas", c'est : est-ce que ton FTP est en bien en mode "Automatique" ?
C'est dans ton compte sur le web sous la rubrique "Gestion FTP". En effet, bien que le déclenchement soit prévu par 1fichierfs, comme je ne teste jamais en mode "Manuel", il y a peut-être un problème dans ce mode.
Tant que tu y es, coche aussi pour demander un "rapport par e-mail", ça aidera à comprendre. L'hypothèse en cours serait donc que tu es en "Manuel" et qu'il n'y a jamais de "déclenchement". Ainsi, les fichiers uploadés restent sur le serveur FTP et ne vont jamais sur le stockage. En mode "Manuel", s'il n'y a pas eu de "déclenchement", les fichiers sont supprimés du serveur FTP au bout de 24h.
L'idéal pour vérifier cela est de te connecter à ton compte FTP, avec Filezilla par exemple, dans les 24h à la place de 1fichierfs. Regarde l'identifiant qu'il a créé, et le mot de passe est ta clé d'API. Si tu vois plein de fichiers (tes 600Go) sur le compte FTP et qu'au bout de 5 minutes ça n'a pas l'air de bouger, c'est ça !
En mode "Manuel" tu peux tenter de débloquer la situation en faisant toi-même un déclenchement sur la page Web... donc si tu t'es déjà remis en "Automatique", repasse en "Manuel" puis Déclenchement, et retour en mode "Automatique".
Là ça devrait bouger, puis quand le serveur FTP est vidé, tu relances 1fichierfs pour qu'il fasse la fin du job !..

Dernière modification par Zakhar (Le 22/10/2025, à 21:14)

Jarodd · Le 24/10/2025, à 16:33

Bonjour,

Désolé pour le "ça marche pas", j'ai bien dit que je n'avais pas pu aller plus loin dans mes tests

Je viens d'activer le FTP en automatique + les rapports.
Je reçois bien les rapports, sous cette forme :

FTP - Rapport de publication :
F1axxxxx_000xxxx
Status : OK - 2.16 Go
Lien de téléchargement : https://1fichier.com/?xxx
Lien de suppression sur votre console de gestion

Mais sur l'interface 1F, je ne vois toujours pas le fichier, même après avoir attendu plusieurs heures. J'ai testé sur plusieurs navigateurs, navigation privée, etc. cela ne change rien. Je n'ai donc aucune certitude que le fichier est bien présent (même si le rapport semble dire que oui).

Edit : j'ai fait un autre test : j'ai transféré une vidéo. J'ai reçu l'e-mail de succès. Mais si j'essaye de lire la vidéo, VLC affiche un message "Votre média d’entrée ne peut être ouvert:
VLC ne peut pas ouvrir « file:///home/moi/1fichier/video.mkv ». Vérifier les messages du journal pour plus de détails."
Le fichier d'origine est correctement lu, les deux fichiers font la même taille, à l'octet près.
Donc il y a une corruption du fichier transféré, je ne sais pas où ni pourquoi. Cela explique peut-être qu'il ne soit pas visible dans l'interface 1F.

Dernière modification par Jarodd (Le 24/10/2025, à 22:00)

Zakhar · Le 25/10/2025, à 10:34

Merci pour les tests.

Donc tu confirmes :
- 1fichierfs transfère bien le fichier via FTP puisque tu reçois l'e-mail
- Du fait que tu fais le test avec vlc, je déduis que 1fichierfs te montre le fichier ainsi transféré (même s'il n'est pas lisible).

Désolé alors pour avancer l'application la plus plausible : le compte que tu vérifies via l'interface web est un autre compte (compte gratuit "inscrit", etc...)

Pour avancer dans les tests :
- via le processus "standard" de 1fichier.com, un fois que tu as reçu le lien de téléchargement, essaye de l'utiliser pour télécharger ton fichier à un autre emplacement et vérifier avec le fichier d'origine.
- via 1fichierfs, le mieux est de vérifier le fichier uploadé, tel que 1fichierfs te le montre, par rapport à ton fichier d'origine.

Vérification des fichiers :

diff -s /chemin1/fichier_origine ~/1fichier/chemin2/fichier_sur_le_cloud

Personnellement j'utilise l'utilitaire pv qui est bien sympa parce qu'il met une jauge de progression. Il faut l'installer (sudo apt install pv) et la commande devient alors :

pv /chemin1/fichier_origine | diff -s -  ~/1fichier/chemin2/fichier_sur_le_cloud

Sur un petit fichier, ça ne fait guère de différence, sur un gros fichier, diff (sans pv) va rester silencieux jusqu'à la fin de la comparaison du fichier et tu peux te demander si c'est "planté" ou pas, tandis que pv montrant la progression, on voit bien que ça avance !

ATTENTION : 1fichierfs te montre le fichier copié, aussi bien pendant la copie qu'après celle-ci. Une fois la copie finie, même si 1fichierfs te montre le fichier avec sa taille exacte, celui-ci n'est pas accessible pendant "un certain temps".
Comme déjà expliqué plus haut le "un certain temps" est dû au processus d'upload vers 1fichier.com avec l'usage de FTP. On a donc 5 minutes (temps d'attente de déclenchement FTP) + 30sec + ~14sec par giga. Une fois ce temps écoulé, le fichier apparaît apparaît dans ~/1fichier/.upload.1fichierfs, et là 1fichierfs le déplace et le renomme vers l'endroit voulu. Le "travail" de 1fichierfs s'arrête là pour ce fichier, et le fichier est bien visible y compris dans l'interface web standard, mais cependant celui-ci n'est toujours pas accessible. En effet, le serveur fait des "vérifications" (par exemple anti-virus) et pendant ces "vérifications", le fichier est verrouillé par le serveur. Il n'est accessible (lecture/téléchargement) ni via le web, ni via 1fichierfs pendant ces "vérifications".

Avec la commande diff ci-dessus (avec ou sans pv) tu auras un message clair du genre "Périphérique ou ressource occupé", qui indique bien la chose.
Ton test avec VLC n'est pas le mieux parce que VLC étant un outil graphique ne va pas forcément te remonter ce message précis, mais sans doute effectivement un truc générique disant que le fichier ne peut pas être lu... simplement parce que tu n'as pas attendu assez longtemps.
Ensuite, même si ça fonctionne avec VLC, tu ne vas vérifier que les portions du fichiers que tu visionnes, et pas l'intégralité du fichier comme le fait un diff.

Donc la poursuite du test, comme je te l'indiques :
- Uploader un fichier
- Attendre le message par e-mail
- Vérifier qu'on voit bien le fichier sur 1fichierfs
- faire le "diff", tant qu'on a le message indiquant que le fichier est occupé, il faut attendre.... désolé, c'est le processus incompressible de 1fichier.com
- une fois que le "diff" fonctionne, avec l'option "-s" il devrait dire "fichiers identiques".
- Là tu peux tester avec VLC s'il s'agit d'une vidéo
- Avec ce cycle complet tu auras un fichier sauvegardé, vérifié et accessible, via 1fichierfs.
- Là tu peux alors vérifier avec l'interface web... mais attention de bien de connecter avec le compte correspondant à la clé d'API utilisée par 1fichierfs !..
- Tu peux aussi à ce moment là, utiliser le lien de téléchargement fourni par l'e-mail de confirmation, télécharger localement à un autre endroit (par exemple /tmp) et vérifier que le téléchargement et le fichier d'origine sont bien les mêmes (diff)
- Si tu n'es pas connecté à ton compte, cliquer sur le lien de téléchargement va te demander de te connecter. Attention d'utiliser le bon compte !

Dernière modification par Zakhar (Le 25/10/2025, à 10:40)

Jarodd · Le 25/10/2025, à 15:16

Bonjour,

Zakhar a écrit :

Donc tu confirmes :
- 1fichierfs transfère bien le fichier via FTP puisque tu reçois l'e-mail
- Du fait que tu fais le test avec vlc, je déduis que 1fichierfs te montre le fichier ainsi transféré (même s'il n'est pas lisible).

Oui et oui.

Je n'ai qu'un seul compte, qui est premium gold, et je suis bien connecté avec lui. La page console/index.pl indique ceci :
1fichier
Je fais les tests d'ici la fin du week-end

Edit : je pense que mon installation (ou configuration) est foireuse. Un upload via l'interface 1F me montre bien le fichier une fois l'upload fini, par contre il n'apparaît jamais sur mon montage (video de 25 Mo, j'ai attendu 30mn après la réception de l-e-mail).

Dernière modification par Jarodd (Le 25/10/2025, à 16:04)

Zakhar · Le 26/10/2025, à 10:26

Alors donc pour aller plus loin que ce qu'on sait déjà fonctionner, il te faut rajouter un niveau de debug, ainsi :

--log-level=6 --log-file=/tmp/debug.txt

Ensuite tu fais un upload, et tu observes le fichier log, ici : /tmp/debug.txt

Voici mes opérations.
Création d'un fichier au contenu aléatoire de 1Go

dd if=/dev/random of=/tmp/random_file bs=1M count=1024

Upload de ce fichier dans mon répertoire de test :

pv /tmp/random_file >~/1fichier/Divers/Test/random_file

(Si tu n'as pas pv, tu peux remplacer par cat ou même une simple copie par cp ou via l'outil graphique).

Et voici comment ça se manifeste dans le fichier journal :

[1fichierfs    95.486] INFO: <<< API(in) (iReq:14) folder/ls.cgi POST={"folder_id":12345678,"files":1} name=Divers
[1fichierfs    95.578] INFO: >>> API(out) (iReq:14) retry=0 json size=2814 hCode=200
[1fichierfs   186.829] INFO: <<< API(in) (iReq:15) folder/ls.cgi POST={"folder_id":123456789,"files":1} name=Test
[1fichierfs   186.925] INFO: >>> API(out) (iReq:15) retry=0 json size=3279 hCode=200
[1fichierfs   249.365] NOTICE: Transfer[0] of size=1073741824 ended with 0
[1fichierfs   249.365] INFO: <<< API(in) (iReq:16) folder/mkdir.cgi POST={"folder_id":12345678,"name":"F1a3f54b72d646dbe_00000001G0000000000123456!#%random_file"} name=F1a3f54b72d646dbe_00000001G0000000000123456!#%random_file
[1fichierfs   249.453] INFO: >>> API(out) (iReq:16) retry=0 json size=103 hCode=200
[1fichierfs   249.453] INFO: >> Refreshing on mkdir .upload.1fichierfs=0x7f89d0024930.
[1fichierfs   361.152] INFO: <<< API(in) (iReq:17) user/info.cgi POST={} name=/
[1fichierfs   361.244] INFO: >>> API(out) (iReq:17) retry=0 json size=583 hCode=200
[1fichierfs   554.454] INFO: <<< API(in) (iReq:18) ftp/process.cgi POST= name=
[1fichierfs   554.550] INFO: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #226"}.
[1fichierfs   554.550] INFO: >>> API(out) (iReq:18) retry=0 json size=55 hCode=200
[1fichierfs   597.549] INFO: <<< API(in) (iReq:19) folder/ls.cgi POST={"folder_id":12345678,"files":1} name=.upload.1fichierfs
[1fichierfs   597.641] INFO: >>> API(out) (iReq:19) retry=0 json size=890 hCode=200
[1fichierfs   602.641] INFO: >> Refreshing on polling .upload.1fichierfs=0x7f89d000c330.
[1fichierfs   602.641] INFO: <<< API(in) (iReq:20) folder/ls.cgi POST={"folder_id":12345678,"files":1} name=.upload.1fichierfs
[1fichierfs   602.737] INFO: >>> API(out) (iReq:20) retry=0 json size=890 hCode=200
[1fichierfs   607.737] INFO: >> Refreshing on polling .upload.1fichierfs=0x7f89d0021010.
[1fichierfs   607.737] INFO: <<< API(in) (iReq:21) folder/ls.cgi POST={"folder_id":12345678,"files":1} name=.upload.1fichierfs
[1fichierfs   607.833] INFO: >>> API(out) (iReq:21) retry=0 json size=890 hCode=200
[1fichierfs   612.833] INFO: >> Refreshing on polling .upload.1fichierfs=0x7f89d000c330.
[1fichierfs   612.833] INFO: <<< API(in) (iReq:22) folder/ls.cgi POST={"folder_id":12345678,"files":1} name=.upload.1fichierfs
[1fichierfs   612.925] INFO: >>> API(out) (iReq:22) retry=0 json size=1256 hCode=200
[1fichierfs   612.925] INFO: <<< API(in) (iReq:23) file/mv.cgi POST={"urls":["https://1fichier.com/?abcdefghijkl"],"destination_folder_id":12345679,"rename":"random_file"} name=(null)
[1fichierfs   613.041] INFO: >>> API(out) (iReq:23) retry=0 json size=104 hCode=200
[1fichierfs   613.041] INFO: >> Refreshing on write Test=0x7f89cc01a030.
[1fichierfs   613.041] INFO: >> Refreshing on write .upload.1fichierfs=0x7f89d00206e0.
[1fichierfs   613.041] NOTICE: successfuly moved `F1a3f54b72d646dbe_00000001F` to /12345679/ `random_file`
[1fichierfs   613.041] INFO: <<< API(in) (iReq:24) folder/ls.cgi POST={"folder_id":12345678,"files":1} name=.upload.1fichierfs
[1fichierfs   613.145] INFO: >>> API(out) (iReq:24) retry=0 json size=890 hCode=200
[1fichierfs   613.145] INFO: <<< API(in) (iReq:25) folder/ls.cgi POST={"folder_id":12345678,"files":1} name=F1a3f54b72d646dbe_00000001G0000000000123456!#%random_file
[1fichierfs   613.237] INFO: >>> API(out) (iReq:25) retry=0 json size=170 hCode=200
[1fichierfs   613.237] INFO: <<< API(in) (iReq:26) folder/rm.cgi POST={"folder_id":12345679} name=/.upload.1fichierfs/F1a3f54b72d646dbe_00000001G000000000015CC45!#%random_file
[1fichierfs   613.337] INFO: >>> API(out) (iReq:26) retry=0 json size=47 hCode=200
[1fichierfs   613.337] INFO: >> Refreshing on rmdir .upload.1fichierfs=0x7f89d0021010.

Suivons pas à pas ce qui est fait.
On demande une copie vers ~/1fichier/Divers/Test

-Requête 14 (iReq:14) => Lecture du répertoire /Divers
-Requête 15 => Lecture du répertoire Test dans /Divers
- Notice : le fichier est bien transféré (code retour 0) on voit bien qu'il y a 1Go : size=1073741824

A partir de là, l'utilisateur a fini sa copie vers ~/1fichier/Divers/Test. Le fichier copié y est visible via 1fichierfs avec la bonne taille, mais il n'est pas encore accessible pendant que toutes les étapes ci-dessous se passent automatiquement en tâche de fond dans le driver. A ce niveau, le fichier n'est pas encore visible sur le stockage (page web 1fichier.com), mais il est bien visible si on se connecte au serveur FTP.

-Requête 16 => Création du répertoire "marqueur" dans /.upload.1fichierfs. On voit bien le nom du fichier (random_file) à la fin du nom du répertoire marqueur.
-Requête 17 => non liée à l'upload, il s'agit de la requête pour consulter l'espace disponible.
-Requête 18 => [Au bout des 5 minutes puisque la "Notice" de fin d'upload est à 249 sec et on est à 554 sec = + 305sec] Déclenchement FTP. Cela échoue puisque mon compte est en "automatique". Le message d'échec est clair et 1fichierfs l'ignore tout aussi clairement.
-Requête 19 => 43 secondes plus tard, on estime que le fichier devrait être arrivé sur le stockage, on vérifie donc le répertoire /.upload.1fichierfs
-Requêtes 20 à 22 => Le fichier n'étant pas arrivé, on fait un "polling" toutes les 5 secondes. A la requête 22, le fichier est arrivé.
-Requête 23 => on déplace notre fichier qui est arrivé avec le nom F1a3f54b72d646dbe_00000001F dans .upload.1fichierfs vers la cible désirée : répertoire /Divers/Test et le nom "random_file".
-Requête 24 => relecture du répertoire .upload.1fichierfs qui a été rafraîchi suite au déplacement du fichier ci-dessus
-Requête 25 => lecture du répertoire marqueur (c'est le système qui fait cela pour vérifier son existence)
-Requête 26 => suppression du répertoire marqueur dont on n'a plus besoin puisque le fichier est en place à son endroit définitif

Voila le cycle complet. Chaque retour a bien un hCode=200, c'est ce qui est attendu de l'API.
Si je vais sur la page web 1fichier.com, j'observe bien un fichier random_file dans Divers/Test. Le fichier fait bien 1Go.
Après la requête 23, même si fichier est immédiatement visible dans l'interface web, il est encore verrouillé pendant quelques secondes (~45 sec pour un fichier de 1Go) par le serveur. Une tentative de téléchargement depuis la page standard le précisera, ou une tentative de lecture via 1fichierfs donnera "Périphérique ou ressource occupé". Une fois que le serveur a fini des travaux, le fichier devient lisible normalement.
A noter : 1fichierfs gère une exception à cette règle pour des fichiers plus petits que 4K (4096 octets) en mémorisant leur contenu. Cela permet notamment les suppressions vers la corbeille car les fichiers de marquage contenant des chemins doivent pouvoir être relus tout de suite après leur création. Le cycle complet demeure le même pour ces fichiers là, c'est juste que 1fichierfs les rend lisibles sans délai !

Donc là tout va bien, et c'est ça que tu devrais observer.

[PS : j'ai changé les "folder_id" et les liens évidemment, par contre le début du nom des répertoires marqueur ne transporte aucune donnée confidentielle, c'est juste un timestamp de démarrage du driver !]

[Edit] A NE PAS FAIRE !
Bien sûr tu peux t'amuser à "désynchroniser" cette belle mécanique.
Exemple de chose "débile" pour tout planter :
- Création d'un répertoire : "Films"
- Upload de vidéos vers le répertoire : "Films"
- Pendant que la tâche de fond se déroule... suppression du répertoire "Films" !..

A noter que tu ne peux pas faire cela via 1fichierfs. En effet, comme il va te montrer des fichiers dans ce répertoire, même s'ils ne sont que "en cours de stockage", le kernel ne te laissera pas supprimer un répertoire non vide.
Mais sur l'interface 1fichier.com, comme ton répertoire "Films" est encore vide pour le temps que la tâche de fond se déroule, le répertoire étant vide, tu peux le supprimer via la page web.

Donc là évidemment, on est face à un utilisateur qui l'a fait exprès pour que ça plante... en fait, quand les fichiers vont arriver sur le stockage dans le répertoire de temporaire .upload.1fichierfs, le driver va tâcher de les déplacer où ils étaient désirés, c'est à dire le répertoire "Films", mais celui-ci n'existant plus parce que l'utilisateur a fait exprès de le supprimer via l'interface web... eh bien ça ne va pas fonctionner.
En réalité le cas est prévu, 1fichierfs voyant qu'il ne peut pas finir le process en mettant les fichiers au bon endroit va simplement mettre un message d'erreur dans le journal et laisser les fichiers dans .upload.1fichierfs

Par conséquent, si c'est ce genre de manipulation "tordue" que tu as fait... eh bien c'est normal que les fichiers n'arrivent pas au bon endroit. En fait je fais la manipulation "tordue" pour vérifier explicitement que les défenses du programme contre ce genre de désynchronisation fonctionnent toujours ! Mais c'est juste dans le cadre de test du programme.

Par contre, supprimer les fichiers que tu viens d'uploader puis le répertoire avant même que le "cycle d'upload" soit terminé -c'est à dire quand les fichiers ne sont pas encore visibles sur le web- est toujours possible. C'est codé et testé. 1fichierfs va alors tâcher de les supprimer du serveur FTP avant même qu'ils ne soient stockés, et si ça ne fonctionne pas, ils seront supprimés dès qu'il apparaissent sur .upload.1fichierfs. Tu peux d'ailleurs même supprimer un fichier en cours de copie (oui, c'est possible sur Linux qui fonctionne en "verrouillage optimiste" contrairement à W$ qui ne te laisserait pas faire ça avec le mode "pessimiste"), dans ce cas la copie va continuer mais aller "à toute vitesse" puisqu'en réalité on n'envoie plus rien sur FTP.

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

Zakhar · Le 26/10/2025, à 16:24

(26 octobre 2025) Version 1.9.6

Nouveautés par rapport à la 1.9.5

Fonctionnalité : possibilité de renommer des fichiers chiffrés via encfs-mode paranoIa.
Amélioration : meilleure gestion des chemins internes au montage passés en paramètre.
Documentation : mise à jour de la documentation en 1.9.6.
Documentation : grosse mise à jour du TODO !..
Sécurité ! Fix bugs : un possible "leak" d'information (fichier précédent, mémoire du kernel) avec un pattern d'écriture particulier. Désormais ce pattern d'écriture n'est plus possible: il retourne "Accès refusé".
Fix bugs : divers bugs mineurs (gestion de paramètres).

Mise à jour
Si vous n'utilisez pas encfs, à part le possible leak [sécurité] d'un fichier écrit vers un autre avec un pattern d'écriture particulier, la mise à jour ne vous apportera pas grand chose.

Pistes futures (sans urgence) :
Le fichier TODO a été mis à jour, voir sur le git.
La version de ce jour permet de "cranter" et de repartir sur cette base pour la suite.
En premier, je m'occupe des améliorations pour les utilisateurs "inscrits" (non payant donc) qui peuvent utiliser l'API depuis un certain temps. S'ils tentent d'utiliser 1fichierfs, comme celui-ci n'a pas encore notion de la nuance inscrit/client payant, il est possible que cela déclenche un bannissement temporaire si l'utilisateur essaye de lire des fichiers... ce qui n'est pas possible en "inscrit".
Ensuite j'ai l'algorithme RCU à améliorer/simplifier.

... puis sans doute quelques bugs que j'ai vus sur cette version, notamment quand on tente de renommer un répertoire sur encfs... le renommage de fichiers individuels marche bien lui.

Pour Raspberry Pi, package binaire 64 bits Bookworm, si vous préférez ne pas compiler depuis le source.

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

$ stat -c "%s %n" 1fichierfs_1.9.6~bookworm-1_arm64.deb; sha256sum 1fichierfs_1.9.6~bookworm-1_arm64.deb; md5sum 1fichierfs_1.9.6~bookworm-1_arm64.deb 
108668 1fichierfs_1.9.6~bookworm-1_arm64.deb
18ea40c9f506d50a4fc6889efab4a4d4ccb6780f8a8f2a1ecde4cd69b2978560  1fichierfs_1.9.6~bookworm-1_arm64.deb
8b8c4c87d541b01ab024ce2fdc491821  1fichierfs_1.9.6~bookworm-1_arm64.deb

Dernière modification par Zakhar (Le 29/10/2025, à 12:23)

Zakhar · Le 24/01/2026, à 02:07

Hello les utilisateurs de 1fichierfs.

Le projet continue avec un //TODO long comme le bras.

J'ai fait un gros morceau, j'ai ré-écrit le RCU sous forme d'une bibliothèque source niveau professionnel, et intégré à 1fichierfs.

Au passage et par hasard, j'ai découvert un bug rarissime dans le "moteur" de streaming. Il se produit lorsqu'un fichier a généré un "gap", c'est à dire lu des octets pas encore demandés, et qu'un nouveau logiciel lit le même fichier et tombe juste sur le "gap". La correction (astreamfs_worker.c) est poussée sur le GitLab et sera intégrée à la prochaine version fonctionnelle.

En effet, le changement de RCU est totalement invisible, d'autant qu'il n'est pas vraiment beaucoup sollicité par 1fichierfs dans un usage courant.
La seule manifestation en réalité, c'est qu'il y a quelques lignes de plus de statistiques pour restituer l'état du RCU.

Les deux prochains items visibles de la liste du //TODO sont :
- adaptations pour les "non-clients" (simples inscrits - non payants)
- upload sur le compte FTP principal (ce qui nécessite le mot de passe du compte puisqu'il est lié au FTP principal). Donc ce n'est pas une fonction recommandée pour les "payants" puisque la clé d'API vous protège de donner ce mot de passe. Mais pour les non-payants, comme il n'y a qu'un seul compte FTP (le principal), il n'y a pas d'autre moyen. La fonctionnalité va donc en même temps les adaptations pour les "non clients". A noter que j'ai demandé à la team 1fichier.com de séparer ce mot de passe FTP... pour l'instant ils font la sourde oreille... ce serait pourtant le B.A.-BA de la sécurité de ne pas utiliser le même mot de passe pour le compte et pour FTP, mais bon, on redemandera quand le développement sera fait !

La //TODO list s'est un peu allongée avec une nouvelle fonctionnalité que je n'avais pas remarquée tout de suite : désormais quand vous supprimez des fichiers, que ce soit sur l'interface web ou par 1fichierfs (donc via l'API), ceux-ci vont dans la corbeille. C'est automatique et non débrayable. Interrogée, la Team 1fichier m'a expliqué que c'est une "sécurité". En effet, si on vous vole votre clé d'API... mais pas le mot de passe, la seule chose pour vous emm**der que peut faire le "voleur" c'est de vous détruire vos fichiers. Mais comme ceux-ci vont dans la corbeille, vous avez 30 jours pour les récupérez.
Sachez néanmoins que la "fonctionnalité" existe, elle n'est pas forcément géniale a contrario pour la "privacy" puisque un fichier que vous voulez détruire ne l'est pas vraiment, sauf à aller explicitement sur l'interface web et à le supprimer aussi de la corbeille.
Aussi le fonctionnement est un peu "simpliste". Depuis la corbeille on ne peut que supprimer définitivement ou restaurer vers la racine (et pas à l'endroit d'origine).
Or comme j'utilise encfs en mode "paranoia", celui-ci chiffre les fichiers avec une clé dépendant du chemin complet, donc un fichier chiffré restauré à la racine ne sert à rien : il est illisible !
Je vais donc réfléchir à comment faire plus "intelligemment" pour avoir de quoi restaurer au bon endroit, et je rajoute ça à la //TODO.
Si vous avez un idée à ce sujet, n'hésitez pas à partager.

Dernière modification par Zakhar (Le 24/01/2026, à 02:10)

z3ndra · Le 17/05/2026, à 22:37

bonjour Zakhar, merci pour tes mises à jour.

Effectivement ce bug m'ai arrivé aussi y a pas si longtemps mais c'est rare.

Sinon je fais suite à ton message concernant les fichiers qui se déplacent vers la corbeille c'est effectivement embetant. Mais y aussi une deuxième chose je ne sais pas si tu aurais la réponse si jamais, depuis 3/4 mois je remarque que les statistiques de hot storage et cold storage ne se mettent plus forcément à jour quand des fichiers ont eu un accès, avant ça les prenait bien en compte (logique d'ailleurs puisque les fichiers bah ont une activité c'est justement le principe) mais depuis ils restent automatiquement en cold storage, j'ai essayé avec un autre compte premium et pareil ça n'a pas d'impact sur les ratios chose assez étrange et dérangeante, donc je ne sais pas si tu aurais des infos à ce niveau là ?,si ils ont changé quelque chose car faut aller à la pêche avec eux, la communication n'est pas leur point fort

merci d'avance

Zakhar · Le 13/06/2026, à 10:40

Désolé de la réponse super tardive, la fonctionnalité "suivi" avec réception d'un e-mail ne semble pas fonctionner à 100% !

Le Cold Storage n'est mis à jour qu'à peu près une fois par jour, c'est bien documenté dans leur aide en ligne. Quand tu vas voir sur le site, tu as l'info de la dernière mise à jour.
Il est possible qu'il en soit de même pour le Hot Storage, mais lui étant illimité, ça n'a pas trop d'importance.

Par conséquent, effectivement, quand tu changes quelque chose qui a un impact théorique sur l'un ou l'autre... eh bien tu ne vois rien avant parfois le lendemain. Le driver redemande bien les compteurs à chaque changement impactant qu'il voit, mais il obtient en général exactement les mêmes données !

Sinon je continue d'avancer sur la bibliothèque RCU, mais c'est l'été, donc d'autres priorités (la plage !) et la prochaine mise à jour sera... quand ce sera prêt, comme la devise Debian !

Dernière modification par Zakhar (Le 13/06/2026, à 10:43)

z3ndra · Le 01/09/2026, à 09:42

salut, depuis hier soir je ne comprends pas j'ai dans dossier monté certains fichiers accéssibles et donc non, je ne sais pas si c'est un probleme de 1fichierfs ou de l'api de 1fichier, ils ont l'air d'avoir fait une mise a jour de leur interface.

merci d'avance

Zakhar · Le 01/09/2026, à 10:30

Bonjour, personnellement je ne vois rien d'anormal de mon côté. La team 1fichier aurait fait un changement "cassant", ils m'auraient prévenus !

Comme d'habitude :
- est-ce que le problème est identique en utilisant l'interface "officiel" (le site web)
- un journal (log) pour que je voie d'où pourrait venir un éventuel souci, vu que je n'ai rien constaté de mon côté

[Edit] Il peut arriver qu'un serveur soit "en panne" chez 1fichier, auquel cas, les fichiers qui y sont hébergés deviennent effectivement temporairement inaccessibles, le temps qu'ils soient migrés ailleurs. S'il s'agit de ce genre de panne, le fichier est tout aussi inaccessible via l'interface standard, et elle te donne l'URL du serveur fautif (1fichierfs le donne aussi si tu as activé la log).
Il n'y a alors pas grand chose à faire, sauf à la signaler gentiment à la team 1fichier qui est en général déjà au courant car ils ont de la surveillance.

Dernière modification par Zakhar (Le 01/09/2026, à 12:23)

z3ndra · Le 01/09/2026, à 15:33

bah écoute je pensais bien que c'était ça mais du coup tout les fichiers sont devenu de nouveau accessible tout seul ^^

Zakhar · Le 01/09/2026, à 19:54

Voilà ! Toujours le réflexe à avoir, c'est de tester avec l'interface "officiel" (site web) lorsque tu as un souci. Si l'interface "officiel" ne fonctionne pas non plus, ça ne vient ni de l'API, ni de 1fichierfs.
En l'occurrence, tes fichiers inaccessibles avec 1fichierfs via l'API auraient été tout aussi inaccessibles en utilisant le site web.

Parfois un serveur ça tombe en panne, surtout sur le nombre, mais la Team 1fichier s'en aperçoit et répare. Donc, effectivement, ça "tombe en marche" sans que tu n'aies rien à faire au bout d'un moment !

Dernière modification par Zakhar (Le 01/09/2026, à 19:55)

Jarodd · Le 03/10/2026, à 09:56

Bonjour,
Je retente un abonnement 1Fichier, après des déboires liés à mon ancien abonnement.
Est-ce que le message #1 est toujours valable pour l'installer ? Il est de 2018, dernière édition 2022, je ne voudrais pas le suivre s'il n'est pas à jour Et si la doc à jour est au milieu des 23 pages, ça va être compliqué ^^
Merci d'avance.

Dernière modification par Jarodd (Le 03/10/2026, à 10:58)

Zakhar · Le 03/10/2026, à 10:20

C'est toujours aussi simple pour installer... du moins si tu n'es pas en 26.04 parce que je n'ai pas encore refait de version depuis la 26.04, cela dit l'exécutable de la 24.04 semble y fonctionner sans problème.

Donc c'est toujours aussi simple, après avoir ajouté le PPA comme indiqué au post #1 que :

sudo apt install 1fichierfs

D'ailleurs le post #1 est à peu près à jour car je le modifie à l'occasion.

Dernière modification par Zakhar (Le 03/10/2026, à 10:44)

Jarodd · Le 03/10/2026, à 12:47

Merci, en effet c'est resté très simple !
Je n'ai pas trouvé de réponse à une question. La copie de nouveaux fichiers, ainsi que leur suppression, fonctionnent bien. En revanche, pour les fichiers existants qui sont modifiés, je n'arrive pas à l'écraser.
J'ai l'erreur

Erreur lors de l’ouverture du fichier « /path/monfichier » : Permission non accordée

Tous les (sous-)répertoires du fichier sont en 775, et j'en suis le propriétaire :
/home/jarodd/mnt/1fichier/path/
Et /home/jarodd/mnt/1fichier/path/fichier est en 555. Les nouveaux fichiers sont créés avec ces permissions, donc une fois créés, je ne peux plus les écraser non plus !
Aucun chmod ne peut changer cette valeur.
Comment faire pour que les fichiers soient "écrasables" ?

Zakhar · Le 03/10/2026, à 19:52

C'est "work as design" (fonctionne comme prévu). En effet, le mode écriture sur 1fichier.com, comme sur la majorité des services cloud, ne permet pas de modifier un fichier existant.

Tu peux seulement écrire un nouveau fichier, comme tu le constates et aussi bien sûr effacer ce qui existe.

En gros, la "modification" n'est pas possible, et ce n'est pas une limitation de 1fichierfs, mais du service 1fichier.com lui-même. La seule solution est d'effacer le fichier (ce qui fonctionne selon ton message) et tout ré-écrire.

Donc aucun chmod ou autre commande ne te permettra, hélas, de rendre "modifiable" les fichiers car il faudrait passer outre une limitation du serveur lui-même qui ne permet pas cela !
La réponse "permission refusée" est le plus proche de ce qu'on peut imaginer pour cette fonction "impossible", et c'est bien 1fichierfs qui analyse que la chose est impossible et donc renvoie cela. On pourrait aussi retourner "fonction non implémentée", mais ce serait confusant pour beaucoup de logiciels qui ne s'attendent pas à ça en ouvrant un fichier !

Pour certains logiciels, il y a cependant des façons de faire malgré cette limite. Je pense par exemple à rsync, il faut lui demander de faire un synchro avec checksums, car on ne peut pas non plus changer les dates sur le serveur, le fichier prend la date de son upload, et aussi lui demander de tout mettre à jour quand il y a une différence. Ainsi rsync va alors copier le fichier modifié en entier vers un nom temporaire, et à la fin de la copie il renomme le fichier temporaire, ce qui supprime l'ancien.
Pour d'autres logiciels... bah, il faut chercher s'il y a des options qui permettent, comme rsync, de tout ré-écrire quand tu veux faire une modif. C'est certes un peu pénible, et la limite de la chose. Si tu as un fichier de 10Go avec un seul octet qui a changé, tu ne peux pas écrire ce seul octet, il faut ré-écrire les 10Go.

Désolé, mais tu buttes là sur une limite du modèle "stockage en cloud" !

Pour les droits, pas la peine d'essayer de faire un chmod sur les fichiers ou répertoires dans le montage, c'est implémenté en NOOP (no opération), c'est à dire que ça ne retourne pas d'erreur, mais ça ne fait absolument rien !
En réalité, les droits de toute l'arborescence sont tous hérités des droits du répertoire de montage, en appliquant par dessus les éventuels "masques" que tu as précisés au montage le cas échéant.
Seule exception à cela, si on t'a mis des "partages" en mode "read only", le répertoire partagé et ses sous répertoires seront bien sûr forcés read only aussi.
Exemple de masque : l'option noexec. Dans ce cas, tous les fichiers seront forcés comme "non exécutables". Les répertoires eux continueront d'hériter des droits du répertoire de montage.

Si tu as un cas d'usage qui nécessiterait vraiment la "modification", n'hésite pas à le décrire ou au besoin en message privé... mais peu d'espoir que ça fonctionne simplement !

Dernière modification par Zakhar (Le 03/10/2026, à 22:10)

Zakhar · Le 03/10/2026, à 22:17

Plusieurs erreurs !

On évite en général de monter un FUSE en root. C'est bien sûr possible, mais ça ouvre des brèches pas cool vu que le driver tourne en espace utilisateur qu'il est largement plus facile d'attaquer.
Bien sûr, ça fonctionne en root en faisant les réglages nécessaires, mais c'est à n'utiliser que quand vraiment on ne peut pas faire autrement.

Ensuite ta première commande a probablement monté correctement, je présume que la commande est dans le /etc/fstab. Le message est juste un warning.

Avec la deuxième commande tu remontes sur un montage déjà existant, et à part d'avoir précisé --no-empty, ça ne fonctionne pas, et ça donne effectivement l'erreur que tu constate.

Tout ce que je dis n'est pas propre à 1fichierfs, mais valable pour tout montage FUSE en général ! Lis bien la doc de FUSE.

Donc si tu t'es trompé dans le montage, il faut démonter, et ça ne se fait pas par umount, mais par

fusermount -u /mnt/1fichier

(précédé par sudo si vraiment tu as besoin que ce soit root !)

Si ça peut te donner des idées, ma ligne dans le /etc/fstab

1fichierfs /home/zakhar/1fichier fuse ipv4,api-key=@/home/zakhar/.1fichier.key,refresh-file=\!000_refresh.txt,refresh-time=20,log-level=6,log-file=/tmp/debug.txt,stat-file=.stats,no-ssl=/.crypt,no-ssl=/Divers/Test/,encfs=/.crypt,user,noauto 0 0

Explications :

1fichierfs : le programme à lancer pour monter
/home/zakhar/1fichier : le point de montage
fuse : le type de montage
ipv4 : n'utiliser que ipv4 (pas ipv6)
api-key=@/home/zakhar/.1fichier.key : fichier qui contient la clé d'API
refresh-file=\!000_refresh.txt : fichier fictif qui va apparaître sur la racine du montage et permet en l'ouvrant de rafraîchir toute l'arborescence
refresh-time=20 : timer de rafraîchissement en minutes, donc quoi qu'il arrive, au bout de 20 minutes, l'arborescence est rafraîchie.
log-level=6 : niveau de log, c'est le plus verbeux à part 7 qui est "DEBUG". Note: l'exécutable packagé sur le PPA ne contient pas le code de DEBUG pour des questions de perf/taille, donc mettre 7 ferait juste un message dans la log disant qu'en réalité le programme utilisera juste 6.
log-file=/tmp/debug.txt : fichier où la log est écrite
stat-file=.stats : fichier fictif à la racine permettant d'avoir les statistiques du serveur, simplement en affichant le fichier
no-ssl=/Divers/Test/ : répertoire contenant des fichiers de test bidons, géré sans chiffrement (aucune donnée sensible, c'est du test, du random, etc...)
no-ssl=/.crypt : racine de mon répertoire chiffré par encfs. Comme c'est déjà chiffré, on évite de rajouter du tls par dessus !
encfs=/.crypt : on lui dit aussi que c'est du encfs, ça permet les renommages qui sans cela échouent (car modification de fichier existant précisément !)
user : commande propre à fstab, indique que le "user" (utilisateur) peut monter cela sans droit root.
noauto : commande propre à fstab, ne pas monter cela au démarrage de la machine (à ce moment là on est "root"). En fait dans nemo/nautilus va apparaître un répertoire amovible, cliquer dessus le montera. On peut aussi faire le montage au lancement de session, puisque là on n'est plus "root" mais l'utilisateur en session.
0 0 : je crois bien que ça c'est pour les vérifications automatiques au démarrage, là, à l'évidence, on n'en veut aucune.

Ce qui est important donc, au delà d'options dont tu n'as pas forcément besoin, est bien le user,noauto expliqué plus haut ! Ce sont des options spécifiques pour /etc/fstab qui ne sont pas passées au driver : il ne les comprendrait pas !

Typiquement, voici ce qu'on voit dans le fichier journal au niveau 6 :

$ cat /tmp/debug.txt 
[1fichierfs     0.000] NOTICE: started: Saturday  3 October 2026 at 18:33:44
[1fichierfs     0.000] INFO: successfuly parsed arguments.
[1fichierfs     0.000] INFO: log level is 6.
[1fichierfs     0.000] INFO: Logging to file: /tmp/debug.txt
[1fichierfs     0.000] INFO: Refresh file is: !000_refresh.txt
[1fichierfs     0.000] INFO: Remote tree will be cached for 20 minutes.
[1fichierfs     0.000] INFO: Stat file is: .stats
[1fichierfs     0.000] INFO: user-agent=1fichierfs/1.9.6
[1fichierfs     0.000] INFO: no-ssl for path=.crypt
[1fichierfs     0.000] INFO: no-ssl for path=Divers/Test
[1fichierfs     0.000] INFO: encfs  for path=.crypt
[1fichierfs     0.007] INFO: <<< API(in) (iReq:1) folder/ls.cgi POST={"folder_id":0,"files":1} name=/
[1fichierfs     4.131] NOTICE: Waited 4 seconds for network at startup.
[1fichierfs     4.131] INFO: >>> API(out) (iReq:1) retry=0 json size=701 hCode=200
[1fichierfs     4.131] INFO: adding options=-orw,big_writes,fsname=1fichier.com,subtype=1fichierfs
[1fichierfs     4.131] NOTICE: Init done, starting fuse mount.
[1fichierfs     4.139] INFO: <<< API(in) (iReq:2) folder/ls.cgi POST={"folder_id":11111111,"files":1} name=.upload.1fichierfs
[1fichierfs     4.139] INFO: Asynchronous stream engine succesfully initialised with 4 threads, 64 streams, 131072 block size, 524288 max gap.
[1fichierfs     4.139] INFO: <<< API(in) (iReq:3) user/info.cgi POST={} name=/
[1fichierfs     4.139] INFO: <<< API(in) (iReq:4) folder/ls.cgi POST={"folder_id":12345678,"files":1} name=.Trash-1000
[1fichierfs     4.191] INFO: <<< API(in) (iReq:5) folder/ls.cgi POST={"folder_id":23456789,"files":1} name=todo
[1fichierfs     4.219] INFO: >>> API(out) (iReq:4) retry=0 json size=363 hCode=200
[1fichierfs     4.219] INFO: <<< API(in) (iReq:6) folder/ls.cgi POST={"folder_id":34567890,"files":1} name=files
[1fichierfs     4.227] INFO: >>> API(out) (iReq:2) retry=0 json size=128 hCode=200
[1fichierfs     4.227] NOTICE: last shutdown was clean, nothing to resume.
[1fichierfs     4.227] INFO: <<< API(in) (iReq:7) ftp/users/ls.cgi POST= name=
[1fichierfs     4.227] INFO: >>> API(out) (iReq:3) retry=0 json size=604 hCode=200
[1fichierfs     4.463] INFO: >>> API(out) (iReq:7) retry=0 json size=135 hCode=200
[1fichierfs     4.463] NOTICE: writing with FTP user `1fichierfs-12345567890` in directory `/.upload.1fichierfs`.
[1fichierfs     4.559] INFO: >>> API(out) (iReq:5) retry=0 json size=966 hCode=200
...

Tout tourne sur des roulettes, il me dit qu'il a bien compris mes arguments, me répète les principaux.
Il y a eu un délai de 4 sec au démarrage, car j'ai mis le montage au démarrage de la session, or le réseau démarre alors en parallèle. Dans ce cas 1fichierfs attend "un certain temps" (programmable par option) avant d'abandonner. 4sec c'est dans les tolérances !
A ce moment il démarre le "stream engine" (lecture) avec par défaut la moitié des "core" dispo, donc 4 en l'occurrence sur mon PC à 8 cores (on peut spécifier plus de stream engine si on veut).
Ensuite il s'occupe de la partie écriture, il regarde le répertoire d'upload, il existe et tout va bien, c'est vide, donc pas de "reprise de cycle d'upload à faire".
En info, il m'indique le user FTP utilisé (le mot de passe est la clé d'API), ce qui permet de regarder avec Filezilla par ex, et il indique aussi où sont envoyés les fichiers (/.upload.1fichierfs, c'est "en dur" pour l'instant).
Puis il lit les répertoires à la racine (ça c'est parce que le système les demande juste après le montage).
On voit que toutes les requêtes se terminent bien avec un code 200 OK, donc tout va bien !
etc.

Un petit tour sur les stats, c'est intéressant aussi :

$ cat ~/1fichier/.stats 
Uptime: 04:43:20

Readers:
    Files    Streams  Start streams             Fuse requests
   Cur/Tot.  Cur/Tot. AvgTim MaxTim Down. N.Req AvgTim MaxTim Speed Av.Sp Over.
02: 1     2   1     2 .72728 .99048 16433     2 .00251 .00494     0  9384     0
└─(   1) 0/0  1     1 .46408 .46408    49     1 .00008 .00008     0    72     0
03: 1     2   1     2 .70390 1.0500  589M  4721 .00169 .05589     0 82.7M     0
└─(   2) 0/0  1     1 .35778 .35778  589M  4720 .00169 .05589     0  100M     0
-------------------------------------------------------------------------------
Tt  2     4   2     4 .71559 1.0500  589M  4723 .00169 .05589     0 73.7M     0

API:
                        N.Req  Avg Time  Max Time Retry N.Err
folder/ls.cgi         :    21    0.3631    4.1249     0     0
download/get_token.cgi:     4    0.2541    0.4130     0     0
user/info.cgi         :     2    0.0823    0.0870     0     0
ftp/users/ls.cgi      :     1    0.2347    0.2347     0     0
--------------------------------------------------------------
Total                 :    28    0.3229    4.1249     0     0

         Trig. Timer Poll. Write   API Error  Auto   Total
Refresh:     0     1     1     0     0     0     0       2

             Number Memory
Allocations:  17344   614M
Frees      :  17208   613M
Difference :    136   307K
Contentions:      0      0

Live streams: |Write| 0    (Read) 2
  Ref   Size  Left Lnk Er N.Loc N.Stm Path
(   1)    49 00:00   1        1     1 /.crypt/8jAmcUwiS,EFy-YtyJnRbnmb
(   2) 19.9G 29:47   1        1     1 /.crypt/02JF5KqYnlrgTI6Ez4-z19Yu/pAiyF-kmIeiQ2p1ntygczQlXe9QyxLTU,HLbJQy7oqyrDfHm71uEx,Mbn,ALeBB33lIOqYCUFzK4m7U7Nilq0S93

J'ai fait un test de copier un fichier chiffré (d'où le nom bizarre) de 20G, juste le début puis coupé par CTRL-C.

On voit qu'il s'est positionné sur le thread 3 et que la copie tournait à 100M octets par seconde !
La moyenne avec les autres petit fichiers reste à plus de 73Mo/s !

Les temps sont excellents aussi sur les APIs. On a un 4.12 sec sur une lecture de répertoire, mais c'est dû au démarrage du réseau qui a mis 4 secondes.

On voit 1 seul refresh sur timer alors qu'on tourne depuis plus de 4h et qu'on a mis 20min de refresh... C'est normal ! En fait au bout de 20 minutes les entrées en cache sont marquées "à rafraichir", mais on ne fait aucun accès au serveur tant que personne ne le demande. Si un accès se produit et que la cache est marquée, seulement à ce moment là on ira relire les répertoires au serveur, et seulement les répertoires demandés par l'application cliente !

Dernière modification par Zakhar (Le 03/10/2026, à 23:27)

Jarodd · Le 04/10/2026, à 14:27

C'est trop technique pour moi, je vais me contenter de faire un copier coller
Merci pour le suivi.

Zakhar · Aujourd'hui à 10:52

La strict minimum pour le fichier /etc/fstab est :

1fichierfs /home/zakhar/1fichier fuse api-key=@/home/zakhar/.1fichier.key,user,noauto 0 0

Et tu mets la clé d'API dans le fichier désigné par la commande.

Tout le reste est fonctionnalités dont tu n'as effectivement pas forcément besoin :
- rafraîchissement : utile si tu as 2 montages sur 2 machines en parallèle et qu'une des deux écrit/renomme des fichiers, ou si tu te sers de l'interface standard en même temps que le montage.
- fichier journal : pour constater ce qui ne va pas en cas de problème
- encfs : a l'évidence si tu l'utilises, sinon c'est inutile
- non chiffrement : raffinement pas totalement utile sur un PC rapide (mais bienvenu sur un Pi par exemple)
- statistiques : c'est joli... ça aide aussi au debug s'il y a des problèmes, mais pas totalement indispensable

Il y a aussi tout un tas d'autres options que tu peux voir en consultant le manuel ou l'aide

man 1fichierfs
1fichierfs --help

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#551 Le 22/10/2025, à 20:02

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

#552 Le 24/10/2025, à 16:33

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

#553 Le 25/10/2025, à 10:34

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

#554 Le 25/10/2025, à 15:16

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

#555 Le 26/10/2025, à 10:26

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

#556 Le 26/10/2025, à 16:24

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

#557 Le 24/01/2026, à 02:07

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

#558 Le 17/05/2026, à 22:37

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

#559 Le 13/06/2026, à 10:40

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

#560 Le 01/09/2026, à 09:42

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

#561 Le 01/09/2026, à 10:30

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

#562 Le 01/09/2026, à 15:33

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

#563 Le 01/09/2026, à 19:54

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

#564 Le 03/10/2026, à 09:56

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

#565 Le 03/10/2026, à 10:20

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

#566 Le 03/10/2026, à 12:47

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

#567 Le 03/10/2026, à 19:52

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

#568 Le 03/10/2026, à 22:17

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

#569 Le 04/10/2026, à 14:27

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

#570 Aujourd'hui à 10:52

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

Pied de page des forums