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

Zakhar · Le 22/10/2025, à 19: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, à 20:14)

Jarodd · Le 24/10/2025, à 15: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, à 21:00)

Zakhar · Le 25/10/2025, à 09: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, à 09:40)

Jarodd · Le 25/10/2025, à 14: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, à 15:04)

Zakhar · Le 26/10/2025, à 09: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, à 10:52)

Zakhar · Le 26/10/2025, à 15: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, à 11:23)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

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

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

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

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

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

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

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

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

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

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

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

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

Pied de page des forums