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

Zakhar · Le 21/10/2019, à 18:20

jaxx21 a écrit :

Merci. C'est clair , 2 To c'est good sur Raspberry. Je testerai à l'occasion. Merci à toi.

Si tu as un bon réseau chez toi, genre fibre !..
Sinon c'est moyennement utile d'avoir des choses en cloud.

Je suis chez Free, et en heure creuse je parviens à saturer la fibre à 1Gbps, c'est à dire que l'accès à mes fichiers sur 1fichier est aussi rapide que d'accéder à des fichiers sur mon réseau local !..

Comme le stockage "Cold" de base est de 2To chez 1fichier, tu peux avoir ce volume là, plus tout ce qui est dans le "hot", c'est à dire a été partagé il y a moins de 60 jours (règle actuelle).

Exemple !

$ df -h ~/1fichier
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
1fichier.com       2,4T    1,5T 1013G  59% /home/zakhar/1fichier

Pour ton test sur Raspberry Pi, vérifie que tu as la bonne version. Il est cependant possible que ça marche sur celle d'avant, mais ça pourrait créer des bugs aléatoires !

tartho77 · Le 22/10/2019, à 08:41

Bonjour,

Je suis intéressé pour installer ce « plug-in » sur mon serveur Plex (qui est un NAS) pour accéder directement à mes vidéos présente sur mon compte 1fichier.
Cependant, je ne comprend pas la marche à suivre.

Pourriez-vous m’aider pour installer cela sur mon serveur Plex ?
Merci d’avance.

Zakhar · Le 22/10/2019, à 15:25

Bonjour Tartho77

Malheureusement pour un "NAS", si par cela tu entends une machine locale qui est chez toi, tu vas devoir compiler à partir du source, parce qu'il n'est pas possible de faire un package tout fait pour tout type de NAS. Cela dépend du processeur, de l'O.S., etc...

Malheureusement aussi, la plupart des constructeurs de NAS ont tendance à :

offrir un O.S. minimaliste (sans fuse)
"fermer" l'offre au sens où on ne peut pas "rooter" la machine.

Le point 1 est rédhibitoire. Par exemple sur mon Synology DS413J (qui date un peu maintenant !), le kernel est compilé sans le support de fuse, afin d'en réduire la taille (machine à 512Mo de RAM). Or mon driver s'appuie sur fuse, et sans le support dans le kernel ça ne peut pas fonctionner. Aller jusqu'à recréer un kernel pour mon NAS en incluant fuse n'est tout simplement pas possible, du moins hors de portée, car pas du tout documenté par le constructeur.

Le point 2 est une "politique" de plus en plus suivie par les fournisseurs de NAS. A la glorieuse époque de mon DS 413J, Synology abritait encore des pages pour installer la "toolchain" et donc pouvoir rajouter à l'OS de base tout un tas de trucs intéressants, comme par exemple avoir les utilitaires GNU complets au lieu de la version réduite busybox, mais aussi le compilateur C (gcc) pour ses propres programmes. Malheureusement, le "grand public" étant généralement totalement ignare en informatique (ceux qui postent ici le sont déjà un peu moins !), cela devait sans doute poser plus de problèmes qu'autre choses avec des gens qui "avaient vu des posts sur internet" et les appliquaient sans comprendre avec pour conséquence de "casser" complètement l'O.S. de leur NAS. Par conséquent Synology (et les autres qui à la base ne l'avaient pas !) a complètement retiré les pages de documentation sur la "toolchain".
Il n'est donc plus possible de "bricoler" son NAS pour rajouter ce genre de chose.

Cela a cependant été remplacé, pour les NAS les plus puissants, par un modèle en "container". Pouvoir gérer des "container" voire des machines virtuelles (NAS haut de gamme) permet en effet à l'utilisateur de rajouter les outils qui l'intéressent sans "casser" le fonctionnement même du NAS. Au pire il "casse" son container ou sa machine virtuelle.
Dans un container, je doute qu'on puisse rajouter un driver fuse si l'OS host ne le supporte pas. Dans une machine virtuelle, c'est toujours possible, mais ensuite il faut étudier la question d'exposer ce montage à l'OS hôte pour que le NAS voie quelque chose... et ce n'est pas forcément une mince affaire.

Donc malheureusement, et en plus sans le modèle exact de ton NAS, je crains qu'il ne faille abandonner l'idée d'avoir une solution aussi simple que sur Ubuntu ou Raspberry Pi, c'est à dire avec un "package" !

... après, l'intérêt de Raspberry Pi est justement qu'il n'est vraiment pas cher. Si c'est juste pour faire fonctionner 1fichierfs et Kodi, même un bon vieux RPI 3 tient la route, et avec la carte SD et les câbles, tu en as pour largement moins que 100€. Le RPI peut ensuite partager son montage "cloud" avec le NAS, ou avec les machines du réseau local, ça ce n'est pas un problème !

Si maintenant par "NAS" tu entends la même solution que Jaxx21, c'est à dire une machine Cloud chez un fournisseur, celle-ci est généralement déjà à base d'Ubuntu, et c'est donc très facile de rajouter le driver.
C'est 3 lignes de commande : une pour rajouter le ppa, une pour mise a jour du store, et une pour installer !

sudo add-apt-repository ppa:alainb06/astreamfs
sudo apt update
sudo apt install 1fichierfs

Ensuite il faut créer un répertoire où tu veux faire le "montage", c'est à dire l'endroit où tes fichiers sur 1fichier.com seront visibles sur ta machine.
En supposant que tu mettes ça dans tes fichiers (on appelle ça le "home" sur Linux) dans le répertoire ~/1fichier, la version la plus simple du montage consiste à faire :

1fichierfs ~/1fichier

Cela te demandera alors d'entrer ta clé d'API. Consulte la documentation pour ne pas avoir à entrer cette clé "à la main" à chaque fois, il y a plusieurs possibilités plus ou moins sécurisées.

1fcihierfs --help
man 1fichierfs

Enfin, ce n'est pas un "plug-in" Plex ni un "add-on" Kodi... 1fichierfs est un driver fuse, donc un élément du niveau du kernel qui permet de montrer le cloud 1fichier comme si c'était des fichiers locaux. Cela permet alors l'utilisation par n'importe quel programme, puisque ces programmes croiront lire des fichiers locaux. On peut donc s'en servir aussi avec des outils de sauvegarde, ou même en ligne de commande.
C'est pour l'instant en "lecture seule" pour la partie fichiers, même si certains ordres comme la suppression ou le renommage sont implémentés car possibles par l'API.

Dernière modification par Zakhar (Le 22/10/2019, à 15:47)

jaxx21 · Le 24/10/2019, à 09:18

Tout est dit: ma ligne de commande est ensuite 1fichierfs --api-key=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --stat-file=.stats -o allow_other /home/jaxx21/1fichier
J'utilise pas le fichier api ou il y a la clé. Mais en effet, il peut si il veut.
c'est sympa les stats. Sérieux, ton driver est top. 1fichier fonctionne à merveille !!!

Merci

Dernière modification par jaxx21 (Le 24/10/2019, à 09:20)

Zakhar · Le 24/10/2019, à 09:20

Oui les stats c'est sympa !

Accessoirement ça m'a aussi permis de trouver des erreurs parce qu'on voit mieux ce qu'il se passe, c'est donc aussi utile en plus d'être sympa.

ploopie · Le 27/10/2019, à 17:37

Hello @Zakhar, merci déjà pour le travail.

Je test actuellement le driver et voici un constat :

- si je DL le fichier directement à partir de 1fichier (interface web) avec Firefox, j'ai un débit de 9Mo/s (soit peu ou prou le débit max de ma connexion),
https://i.postimg.cc/qRdMZsLX/screenshot-563.png

- si je DL à travers un montage 1fichierfs, je suis plutôt dans les 1Mo/s...même fichier.
https://i.postimg.cc/SRx4wDz8/screenshot-564.png

Pourquoi cette différence ?

Merci bien.

Zakhar · Le 27/10/2019, à 18:12

Bonjour Ploopie,

je viens de faire le test, je n'ai aucune différence notable, environ 1Gbps pour les deux situations, sur mon PC de bureau (bête de course core i7 récent avec une tonne de RAM).

Il faudrait détailler comment tu fais la chose, mais surtout la puissance de ta machine !
Il est vrai qu'utiliser firefox pour donwloader un fichier "local" te fait passer par un certain nombres de couches supplémentaires !
En l'occurrence firefox va utiliser son driver "fichiers locaux", cela sera converti en "range" par le 1fichierfs qui va faire le curl.

De plus, passer par un driver fuse veut dire des aller/retour kernel/userland plus nombreux qu'un DL direct.

Donc cette différence de performance d'un facteur 5 ou 6 pourrait s'observer si tu as un machine vraiment très lente... je dirais du niveau d'un Raspberry Pi zéro !..

Il faudrait donc que tu regardes la charge CPU de ta machine pendant que tu fais les 2 opérations.

Aussi il faut faire le test à la même heure, et pour éliminer les phénomènes de cache sur le serveur 1fichier, commencer par le télécharger une fois.

Sur mon PC (avec top),
- En DL fichier local, firefox tourne à 65/70% CPU et 1fichierfs à 25/30%, on a un load average autour de 1.30
- En DL direct, firefox tourne à 95/110% CPU (et 1fichierfs n'est pas utilisé), on a un load average autour de 0.65

On voit que ça prend donc à peu près deux fois plus de charge d'empiler firefox par dessus le driver 1fichierfs, et en cas de machine limitée, ça peut faire la différence.
Sur mon PC de bureau, comme les CPU ne saturent pas à 100%, il n'y a pas de différence notable entre les deux façons de faire, c'est imperceptiblement plus lent avec le mode "fichier local" car firefox ne semble pas optimisé (il ne prend pas les 100% du CPU comme en mode direct).

Aussi, si c'est pour utiliser firefox l'intérêt est moindre... si tu utilises le driver, c'est pour t'en servir avec d'autres programmes, comme par exemple : VLC, kodi, ou simplement gérer tes sauvegardes.

Pour cela, je te recommande le test avec pv

C'est un petit utilitaire génial qui te permet d'avoir une barre de progression dans des cas où tu n'en as pas, comme une copie de fichiers. pv transforme une lecture en stream, et il est donc idéal pour 1fichierfs.
Donc pour tester la vitesse tu fais :

(un coup de

sudo apt install pv

si tu ne l'as pas déjà)

$ pv ~/1fichier/fichier_de_test >/dev/null
8,03GiO 0:01:55 [71,4MiB/s] [====================================================================================================================================================================>] 100%

Avec pv sur le même test que tout à l'heure, on voit que 1fichierfs tourne autour de 60% de CPU et pv ne prend presque rien autour de 5%.
C'est donc plus "optimisé" qu'avec firefox.

Aussi, ce qui peut faire la différence est le SSL qui est sans doute différent entre firefox et les librairies utilisées par curl.
Tu peux faire le test sans SSL pour voir, il y a une option pour ça dans le driver, ou temporairement retirer SSL de ton cloud 1fichier.

Mais par exemple, sur mon Raspberry Pi 4, le même "pv" en SSL tourne autour de 14MBps, soit 6 fois moins vite que sur mon PC. Avec un top, on voit que 1fichierfs est à 100%, et avec les stats, on voit qu'on n'a un seul stream qui tourne (normal avec pv). Donc là c'est le CPU du Raspberry qui limite à cause de SSL.

Le test sur Raspberry Pi, sur la partie non SSL de mon stockage, donne aussi 1fichierfs à 100%, pv à 20% (plus que sur ma machine de bureau donc !) et on est pas loin des 1Gbps sans être aussi performant que sur un PC.
Donc le CPU y est pour quelque chose.

Pour comparer le comparable, avec un fichier identique en curl direct et via 1fichierfs, j'ai un performance 2 fois moindre avec 1fichierfs, mais dans les deux cas ça plafonne à 100% de CPU (avec SSL). La différence de performance est dues aux copies de buffer qu'on fait entre le kernel et le userland qui sont bien doublées avec fuse.
La seule façon pour accélérer, si la machine est multi-core, c'est d'utiliser des "accélérateurs de téléchargement" qui téléchargent des morceaux... mais dans tous les cas, à cause de fuse, le rapport performance/CPU est moins bon.

C'est la rançon de tout driver fuse hélas, et donc tu verras une différence de perf à partir du moment à ton CPU mouline à 100%... ce qui est donc dépendant de ta machine.
Du reste 1fichier a fait l'option "no SSL" pour ce genre de cas... le driver permet de ne pas utiliser SSL pour des parties distinctes de ton stockage. Personnellement j'ai désactivé SSL sur la partie de mes sauvegardes... puisqu'elle sont déjà chiffrées localement !

En conclusion, si ton usage est la performance, le moins de "couches" tu peux empiler, le mieux c'est !
La performance est déterminée par le "maillon faible". Chez moi, sur mon PC de bureau, c'est la fibre de Free à 1Gbps
Chez toi (et dans une moindre mesure sur mon Raspberry Pi), c'est le CPU qui limite (surtout en SSL).

Donc à toi de voir selon ton usage. Si tu as vraiment besoin de performance, un mode plus "direct" est recommandé. Si le côté "pratique" peut surpasser la perte de performance avec ta machine, alors tu peux utiliser le driver !

[Edit] cela dit, à l'occasion je tâcherai d'implémenter "read_buf" qui est sensé améliorer les choses car le kernel peut alors faire un "splice" ce qui allège le nombre de copies de buffers (ce qui prend le plus de temps).

Dernière modification par Zakhar (Le 27/10/2019, à 21:37)

ploopie · Le 28/10/2019, à 13:36

Merci pour tout cela, mais en fait cela venait d'une mauvaise configuration de ma part (carte configurée en 10Mbps sur mon serveur).
Après passage en 1000Mbps, tout est rentré dans l'ordre et marche parfaitement

J'ai aussi profité pour désactiver le SSL globalement, j'en ai pas besoin tout simplement (j'utilise 1fichier pour Plex exclusivement).

Ma machine est un "vieux" Intel E8400 OC@4Ghz + 8Go RAM + SSD pour l'OS (et un RAID10 pour les backups) mais cela suffit pour mon usage (Plex + PF Sense + Pi-Hole + Server DHCP + Sauvegardes locales).

Un peu hors sujet (ou pas) mais je me permets néanmoins de poser la question :

1) 1fichier distingue le Hot et le Cold storage, et pour cela ils déterminent si un fichier a eu un accès dans les derniers 60j pour déterminer si cela bascule dans le Cold (limité à 2To) alors que le Hot est illimité. La question est donc, y a t'il un moyen de ne pas faire basculer les fichiers en Cold ? Je ne pense pas que le fait de mapper compte comme un accès à chaque fichier, si ?

2) Est-il possible de mapper uniquement un dossier à la racine et son contenu, plutôt que tout le contenu ?

Merci bien

Dernière modification par ploopie (Le 28/10/2019, à 13:46)

Zakhar · Le 28/10/2019, à 18:19

ploopie a écrit :

Merci pour tout cela, mais en fait cela venait d'une mauvaise configuration de ma part (carte configurée en 10Mbps sur mon serveur).
Après passage en 1000Mbps, tout est rentré dans l'ordre et marche parfaitement

Tu me rassures !

ploopie a écrit :

J'ai aussi profité pour désactiver le SSL globalement, j'en ai pas besoin tout simplement (j'utilise 1fichier pour Plex exclusivement).

A toi de voir. Désactiver le SSL sur tout ton stockage t'expose aux indiscrétions sur tes paquets IP où qu'ils voyagent... guère compatible dans l'esprit avec un "Pi-Hole" cité plus bas !
Maintenant, TLS a un coût certain. Si cela se ressent trop sur ta machine, c'est une solution. Le driver permet de laisser SSL activé sur le site, et de ne désactiver qu'une liste de sous-répertoires (et leurs descendants).

ploopie a écrit :

1) 1fichier distingue le Hot et le Cold storage, et pour cela ils déterminent si un fichier a eu un accès dans les derniers 60j pour déterminer si cela bascule dans le Cold (limité à 2To) alors que le Hot est illimité. La question est donc, y a t'il un moyen de ne pas faire basculer les fichiers en Cold ? Je ne pense pas que le fait de mapper compte comme un accès à chaque fichier, si ?

Non, "mapper" son stockage 1fichier n'a pas pour effet d'accéder aux fichiers. La seule chose que ça fait, c'est accéder à l'API qui liste les fichiers !
Après tu pourrais facilement développer un script qui lit 512 octets de tous les fichiers (qui échouerait au bout du 500ème fichier en vertu des limites exposées plus haut), mais le téléchargement "par toi-même" ne compte pas comme un "partage". D'ailleurs je ne sais pas si ça compte quand tout le fichier a été téléchargé, ou si "des bouts" suffisent !..

D'ailleurs voici un exemple de commande qui ferait ça :

find ~/1fichier -type f -exec dd if={} of=/dev/null bs=512 count=1 \;

Car dans "accès dans les derniers 60j", il faut comprendre en réalité "partage" dans les 60j, c'est à dire quelqu'un d'autre à qui tu as donné accès à tes fichiers, et qui y accède. Je ne sais pas d'ailleurs si ça compte avec l'option de partage, car si ça se trouve les liens sont différents.
Si tu prends un peu de recul, le "modèle économique" de 1fichier (et d'autres) est précisément basé sur le fait que les fichiers hébergés ont un très fort taux de partage. Sinon, aucun fournisseur au monde ne serait capable de t'offrir du 2To à ce prix là sans faire de lourdes pertes. En réalité, si tu partages un fichier de 10Go avec 20 utilisateurs, cela fait "virtuellement" 200Go, mais en réalité seulement 10Go de stockage + 20 liens (quelques kilo-octets).
A contrario, le "Cold", fichiers que est seul à utiliser, finit par coûter de l'argent en stockage, et il est légitime de le facturer. Ce n'est en réalité pas tout à fait vrai (et dans le sens du "modèle"). Si tu as récupéré un lien partagé et que tu as "copié dans ton stockage", le lien devient privé, mais pour autant le contenu n'est pas dupliqué. Au bout de 60 jours, si tu n'as pas toi-même partagé ce nouveau lien avec quelqu'un d'autre qui l'a téléchargé, le fichier devient "Cold" même si en réalité il n'occupe que l'espace du lien que tu as dupliqué 60j avant. C'est bien comme ça qu'1fichier arrive à faire ce prix !
Les vrais "Cold" ce sont par exemple les sauvegardes que je fais moi-même et qui sont chiffrées. Il s'agit de fichiers uniques et qui donc ont un taux de déduplication nul et occupent 100% de l'espace juste pour moi. Si tout le monde faisait ça, 1fichier ne pourrait plus tenir les mêmes prix... mais ils ont précisément un "modèle hybride", puisque sur le "sauvegardes uniques", lorsque le quota est dépassé, on a un surcoût à payer.

Bien sûr, on peut toujours imaginer des "solutions pour tricher", mais même si j'en avais en tête, je ne les donnerai pas car cela "casserait" le modèle de 1fichier que j'estime sympathique et à un prix assez imbattable !

ploopie a écrit :

2) Est-il possible de mapper uniquement un dossier à la racine et son contenu, plutôt que tout le contenu ?

Ce n'est pas une fonction prévue actuellement, mais je le met dans la whishlist, et tu l'auras dans une prochaine version.
C'est assez facile à faire : une fonction à appeler au démarrage, mais il faudra juste que je corrige certaines choses "en dur" sur les fichiers statistiques et refresh qui s'attendent à être à la racine du montage (répertoire 0).
Par contre en déplaçant le montage sur un sous-répertoire tu vas perdre la fonction de partage puisque celle-ci ne se voit qu'à la racine... il faut aussi que je voie si j'élimine le montage des sous-répertoire qui sont des partages... si ça complique ou pas !
Bref, penser un peu aux "fonctionnalités" de la modification avant de se jeter dessus !

Dernière modification par Zakhar (Le 28/10/2019, à 18:27)

ploopie · Le 28/10/2019, à 19:02

Je comprends bien mais 1fichier n'a pas toujours utilisé ce système Cold/Hot, seulement depuis 1 ou 2 ans maxi, alors que je suis client chez eux depuis...2010.
Ils parlent bien d'accès, et non de téléchargements complets ou partages. Donc je verrais au fil du temps

Pour le montage de dossier, cela peut-être pratique pour des montages distincts selon les besoins.
Et j'ai aussi réactivé le HTTPS, tu n'as pas tort et la différence est nulle selon mes tests ^^

Zakhar · Le 28/10/2019, à 21:03

Oui, 1fichier essaye de sortir de l'image "trucs illégaux", tu vois de quoi je parle...

Donc faire cette histoire de Cold/Hot, ça permet des "vrais" usage en mode "sauvegarde" (le "Cold") et c'est plus "respectable" !..

En quelque sorte, mon driver légitimise cette position, car on peut bien se servir des fichiers comme s'ils étaient en local (si on a une connexion fibre !). Et j'ai réellement des sauvegardes hébergées chez eux (et chiffrées évidemment, avec chiffrement sur mes machines !).

Aussi, la façon dont ils comptent le Cold/Hot est astucieuse d'un point de vue "marketting" ça permet d'afficher un prix d'abonnement plus bas que la concurrence, et facturer le supplément à ceux qui aiment bien garder des masses de fichiers dont ils n'auront jamais plus besoin... même s'il s'agit de fichiers de toute façon partagés et que ça ne coûte pas un rond de plus à 1fichier qu'une personne supplémentaire les conserve ou pas. Bien vu leur calcul.

Pour la fonctionnalité que tu demandes, elle est effectivement intéressante. Un peu de patience cependant, nous avons deux week-end "prolongés" qui viennent où je ne serai pas à la maison en train de coder.

Dernière modification par Zakhar (Le 28/10/2019, à 21:07)

ploopie · Le 29/10/2019, à 21:41

Oui je comprends bien ton point de vue

Une autre question à 3 francs; j'ai testé une fonctionnalité qui serait bien pratique sur 1fichier mais manquante, la décompression de fichier (un peu comme sur Nextcloud, par exemple) directement sur le montage, voici le résultat:

$ unrar e folder.rar           
UNRAR 5.50 freeware      Copyright (c) 1993-2017 Alexander Roshal

Extracting from folder.rar

Cannot create file.txt
Function not implemented

Je ne sais pas si ça viens de 1fichier, de 1fichierfs ou de mon utilisation qui n'est pas correcte toutefois...

Zakhar · Le 29/10/2019, à 21:55

Non, ton utilisation est correcte !

Ce que tu fais nécessiterait que l'on puisse écrire via le driver, ce que je n'ai pas implémenté.

En réalité j'ai cessé d'être très actif sur le driver quand je me suis pris le choux avec la team 1fichier qui a mis des limites stupides sur la lecture (500 fichiers) sans solution "propre" pour passer outre avec une attente raisonnable.

A partir de ce moment, j'ai compris qu'ils ne voulaient pas vraiment que cela soit de la "vraie sauvegarde", c'est juste du marketing prix et une façade pour faire plus "légal". C'est à ce moment que j'ai cessé d'implémenter l'écriture et d'être très actif. Je fais de la "maintenance évolutive" : réparation des bugs, portage des améliorations que je fais sur le driver "père", évolutions qui paraissent intéressantes (comme ta suggestion de monter à partir d'un sous-répertoire du compte).

Par contre ce que tu peux faire, je le fais en permanence avec mon autre driver "générique" astreamfs avec des fichiers sur ma Freebox, mais ça marche aussi bien avec 1fichierfs, c'est :

$ unrar x ~/1fichier/folder.rar /chemin/sur/un/disque/local

L'option 'e' de unrar extrait dans le répertoire courant, tandis que 'x' fait l'extraction dans un répertoire passé dans le second paramètre. L'option 'e' est donc équivalente à 'x' avec extraction dans '.' (qui désigne le répertoire courant).

Pour que ce soit plus pratique à utiliser, en réalité je me suis créé un script qui fait la chose suivante :
- montage de 1fichierfs
- montage en union avec un répertoire local sur lequel on peut écrire.

Ainsi le montage "union" devient "writable".
Tu peux alors faire la commande que tu cites, copier des fichiers, etc...

Ensuite le même script va repérer les fichiers qui ont été écrits sur la partie disque local et les uploader sur le compte 1fichier.

C'est donc une façon "semi-automatique" de faire les choses, mais qui a certes l'inconvénient de nécessiter du stockage local à raison de la taille des choses qu'on a écrit (parfois plusieurs 10aines de giga dans mon cas)

Je n'ai pas publié le script car il est un peu "en dur", mais je peux mettre son "nettoyage" dans la liste si ça peut aider, et je le publie "pour public averti".

Sauf si 1fichierfs change sa politique, je doute que j'implémente un jour la partie écriture, désolé. Ce d'autant plus que ma solution "semi-automatique" est suffisante à mes usages, même si elle a la contrainte de nécessiter un peu de support local temporairement.

Maintenant il s'agit d'un logiciel open source, fais-toi plaisir si tu veux implémenter l'écriture !..
Seulement, autant il y a des APIs pour la lecture, autant pour l'écriture c'est vraiment zéro, aucune facilité. La tâche est donc plutôt coton pour faire un truc semi-passable.

D'ailleurs la façon la plus "élégante" et dans la philosophie Linux (ne pas refaire ce qui existe) de faire l'écriture, est comme le fait mon script, mais en automatisant les choses.
On pourrait imaginer un programme indépendant qui surveille une arborescence donnée et fait l'upload vers le compte 1fichier.
Au montage suivant, on vérifie les fichiers déjà présent à distance et on les efface localement. C'est élégant et propre, ça ne refait pas des choses qui existent déjà (l'unionfs). Ca permet l'écriture aléatoire sur les fichiers qu'on vient de créer. Mais évidemment, ça a l'inconvénient de nécessiter un support local de taille suffisante pour les fichiers "temporaires" (le temps qu'ils soient uploadés). C'est aussi largement sous-optimisé pour le COW (Copy On Write) dans le cas où on ne change que quelques octets d'un gros fichier : par exemple renommage d'un fichier sous encfs. En effet une telle opération nécessitera le téléchargement de tout le fichier pour changer les quelques octets, et il faudra ensuite tout re-uploader !.. Il y a des façons de faire autrement... mais ça devient fort complexe.
Une solution comme celle que j'évoque (pas le truc complexe pour éviter le CoW) est tout à fait faisable dans un langage comme le script shell. Pas besoin d'aller jusqu'à faire du C, comme pour un driver fuse.

Dernière modification par Zakhar (Le 29/10/2019, à 22:17)

ploopie · Le 29/10/2019, à 22:32

Oui je comprends bien, travailler pour quelque chose qui ne tien pas la route n'est pas soutenable...
De toute façon, j'avoue que mon utilisation en écriture serait vraiment limitée !

Pour un autre cas, j'utilise déjà un script shell qui fait la sauvegarde de plus de 300 fichiers chaque soir, mais par FTP (je l’utilise depuis pas mal d'années, avant même que l'API ne soit publiée..).

Zakhar a écrit :

Je n'ai pas publié le script car il est un peu "en dur", mais je peux mettre son "nettoyage" dans la liste si ça peut aider, et je le publie "pour public averti".

Je ne vais pas dire non, mon usage se limite un peu aux cas que tu décris donc ce serait TOP En effet, je vais me limiter à l'extraction de fichier en local et re-upload.

Zakhar · Le 30/10/2019, à 07:42

Ok, je rajoute le "nettoyage" (chemins en dur, etc...) du script à la liste des "whishlist".

Tu cites FTP par exemple. Il aurait effectivement été plus facile d'uploader en FTP car ça permet la reprise (append). On aurait pu être au moins au même niveau que curlftpfs. Mais voila, pour cela tu as besoin du mot de passe, ce qui contredit l'usage API lequel fonctionne avec la clé d'API. J'ai proposé à la team 1fichier d'autoriser à utiliser FTP avec la clé d'API au lieu du classique user/mot de passe... ils ont trouvé l'idée intéressante, mais c'est tout en bas de la pile des "whishlists"... Donc FTP n'est pas une option car on ne veut pas disséminer le mot de passe à un programme qui tourne en permanence !
C'est significatif du zéro amélioration qui a été fait sur la partie "écriture".

Dernière modification par Zakhar (Le 30/10/2019, à 07:43)

ploopie · Le 30/10/2019, à 11:38

Le mot de passe du FTP n'est pas aussi compromettant que le mdp du compte ou de l'api key, ceci car le FTP ne permets QUE l'upload.
Donc en cas de 'fuite', aucun accès aux données.

(mais je comprends, encore une fois, ton point de vue

PS: un petit point, je n'arrive pas à unmount si le

refresh-time

est trop bas, genre 3. Si je le passe à 30, aucun soucis.

fusermount: failed to unmount /mnt/1fichier: Device or resource busy

Dernière modification par ploopie (Le 30/10/2019, à 16:07)

Zakhar · Le 30/10/2019, à 17:36

Ok Ploopie, je regarderai ça.

La première version brute de montage non-racine est codée et fonctionne en première approche. J'ai encore un peu de raffinement à faire (traiter les erreurs d'entrée) et de tests.

... mais pas ce W.E., absence oblige ! ;-)

Dernière modification par Zakhar (Le 30/10/2019, à 17:38)

Zakhar · Le 30/10/2019, à 19:49

@Ploopie, si tu veux tester sans attendre le package, c'est "commité" sur le gitlab.
Pour compiler, voir instructions sur le post #1.

Il doit encore rester un micro bug car j'ai en sortie de programme un reliquat de malloc de quelques octets (les nouveaux trucs alloués pour la gestion de la fonctionnalité). Et ce qui est bizarre c'est que Valgrind ne détecte rien... c'est peut-être alors un bug du comptage des malloc/free !..
Je vérifierai tout ça ultérieurement quand j'aurai plus de temps un week-end. (Edit: corrigé et "commité", bug de comptage effectivement)

Le nouveau paramètre est tout simplement

--root=path

Et cela monte uniquement le "path" indiqué, avec échec si le path n'existe pas ou n'est pas un répertoire.

Il me reste aussi à tester avec des partages... et sans doute ne pas monter les partages de 'root' car c'est un piège !

Également mise à jour de la documentation (manuel).

Par contre ce soir le serveur d'API renvoie pas mal d'erreur 502 aléatoires... pas facile de tester de façon fiable dans ces conditions, je vais le signaler.
[Edit] La team 1fichier a dit qu'effectivement ils semblent avoir des bugs... ils vont "regarder" !

Dernière modification par Zakhar (Le 31/10/2019, à 12:44)

ploopie · Le 03/11/2019, à 00:42

Merci à toi, je suis OFF toute cette semaine qui viens mais je teste cela dès mon retour

PS: je te laisse aussi un petit log dans mon syslog juste pour avoir ton feedback, mais j’imagine que c’est un ratelimit coté 1fichier?

Nov  3 00:34:59 host 1fichierfs: [1fichierfs  6310.019] ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/download/get_token.cgi` name=`https://1fichier.com/?itrq69j0bv7wk4`.
Nov  3 00:34:59 host 1fichierfs: [1fichierfs  6310.019] ERROR: http_code 403 on get_token json resp.:`{"status":"KO","message":"Excess slots #897"}` for https://1fichier.com/?itrq69j0bv7wk4

Bonne vacances à moi

Dernière modification par ploopie (Le 03/11/2019, à 00:43)

Zakhar · Le 04/11/2019, à 00:36

Oui, c'est la limite dont je parlais qui bloque au bout du 500ème fichier.
Donc les manipulations de nombreux petits fichiers, du genre ta collection de 2000 photos de vacances que tu voudrais bien partager avec ta famille... eh bien ça ne passe pas.

Tout est expliqué un peu plus haut, et il n'y a rien que je ne puisse faire au niveau du driver pour changer cette limite idiote. J'ai pourtant tenté d'expliquer à la team 1fichier que je pouvais appeler un autre API pour "libérer les slots inutilisés" (par exemple les fichiers déjà fermés), ou monter la limite à un nombre plus raisonnable pour que le driver fasse de la "temporisation"... mais ils n'ont rien voulu entendre.

Donc ce que j'ai fait, pour ma musique en ligne par exemple (mes CD numérisés) j'ai tout mis dans un gros iso que je monte quand j'ai envie d'écouter ma musique. C'est un peu moins optimisé car moins "séquentiel", mais ça marche fort bien aussi.

Enfin, encore un fois, je doute qu'il y a vraiment des emplois de l'API aussi évolués que mon driver. Sans doute certains usages pour vérifier si des liens sont toujours "up" ou deux trois scripts pour automatiser des choses.

Dernière modification par Zakhar (Le 04/11/2019, à 00:38)

Zakhar · Le 05/11/2019, à 08:52

Comme je le pensais, le montage sur un partage s'avère plus délicat. Aussi il a révélé des bugs ou plutôt du code pas encore écrit sur certains cas d'usage des partages (liens, renommage, etc...).
La modification va donc prendre un peu plus de temps car je vais tâcher de réparer/finir ce qui ne marche pas (encore) sur certains cas de partage.

Zakhar · Le 10/11/2019, à 14:49

(10 Novembre 2019) Version 1.5.3

Nouveautés par rapport à la 1.5.1

NOUVEAU ! : possibilité de monter seulement une partie du stockage cloud distant (voir ci-dessous)
Crash : crash dans l'usage des répertoires partagés reçus
Amélioration : meilleure gestion des renommages, suppressions et liens dans le cas des partages reçus.
Documentation : mise à jour pour l'option --root.

Nouveau !
A la demande de Ploopie (cf posts plus haut), il est désormais possible de désigner un répertoire distant comme racine du montage.
Le répertoire spécifié doit exister (évidemment !) sinon aucun montage ne sera fait.
On peut aussi monter un partage reçu, avec le respect des options de partage.

Usage de la nouvelle fonctionnalité :

1fichierfs --api-key=xyz123abc --root=/Vacances ~/1fichier

La commande ci-dessus montera le répertoire distant "Vacances", contenant par exemple vos vidéos et photos de vacances, sur le répertoire local 1fichier.

1fichierfs --api-key=xyz123abc --root='/Vacances on matante@free.fr' ~/1fichier

Et dans cet exemple, on pourra monter les partages des photos/vidéos de vacances de "matante@free.fr", que votre tante (ou votre matante pour les québécois !) vient de vous partager, et n'avoir que cela sur le montage !

Faut-il mettre à jour : La mise à jour est importante si vous :
- utilisez des partages reçus (pour éviter les crash)
- souhaitez utiliser la nouvelle fonctionnalité.
En dehors de ces cas, la mise à jour n'apporte pas grand chose de nouveau.

Dernière modification par Zakhar (Le 10/11/2019, à 17:18)

Zakhar · Le 10/11/2019, à 15:02

ploopie a écrit :

un petit point, je n'arrive pas à unmount si le
refresh-time
est trop bas, genre 3. Si je le passe à 30, aucun soucis.
fusermount: failed to unmount /mnt/1fichier: Device or resource busy

De mon côté je n'ai aucun souci avec ça :

$ 1fichierfs -l7 /tmp/1fichier --refresh-time 3 --api-key='@/home/zakhar/.1fichier.key' --log-file=/tmp/dbg.txt 
$ fusermount -u /tmp/1fichier

Pas de message d'erreur, tout est bien démonté.

Tu peux refaire avec les options comme ci-dessus, c'est à dire monter le niveau de verbosité à 7 (-l7 ou --log-level=7) et mettre la sortie dans un fichier (--log-file=/tmp/dbg.txt)

Ensuite tu m'envoie le fichier par PM (Private Message = par mail depuis ce site), ou ici en enlevant les choses "privées" (IP, clé d'API, nom des fichiers) si le bug persiste (après avoir lu les NOTA ci-dessous !)

... par ailleurs, est-ce que tu peux répondre à mon PM (en PM !..) si toujours intéressé ?

NOTA: le message "Device or resource busy" est normal, et ce sur tout montage... quand le device est effectivement occupé, c'est à dire qu'un programme en cours a des ressources ouvertes sur ce device. Cela peut facilement être le cas si on a un Plex, Kodi, etc... qui est en train d'indexer des fichiers sur le device. Pour voir les ressources utilisées, on peut faire par exemple :

$ lsof | grep /home/zakhar/1fichier
encfs      8950                  zakhar    3r      REG               0,49 21713104744        100 /home/zakhar/1fichier/.crypt/mh-rKXk22wR6zC4RGZHZawX1
encfs      8950  8951            zakhar    3r      REG               0,49 21713104744        100 /home/zakhar/1fichier/.crypt/mh-rKXk22wR6zC4RGZHZawX1
encfs      8950  8952            zakhar    3r      REG               0,49 21713104744        100 /home/zakhar/1fichier/.crypt/mh-rKXk22wR6zC4RGZHZawX1

On voit alors que sur le point de montage (/home/zakhar/1fichier) on a des fichiers ouverts. En l'occurrence c'est un iso (le reap de mes CD musicaux) qui est monté au dessus de encfs. Donc dans le cas ci-dessus, /home/zakhar/1fichier est bel et bien occupé et ne sera pas démontable. Il faut au préalable démonter l'iso (et le montage encfs).

Il est donc tout à fait possible que ce que tu aies constaté soit "normal" et que le changement de paramètre fonctionne par "coïncidence" parce que tu as démonté au "bon moment" !
Pour le vérifier, je te suggère de faire le test en montant sur un répertoire qui ne soit PAS indexé par Plex, Kodi, etc... afin d'éliminer ce paramètre.

NOTA 2: il y a un bug connu entre Gnome et les montages fuse... je ne l'ai jamais signalé, donc si ça se trouve personne d'autre que moi ne l'a remarqué ! Si tu montes un iso depuis ton gestionnaire de fichiers graphique (Nautilus/Nemo), cela va faire un montage gvfs. Ensuite si tu démontes ledit montage (clic droit + démonter), en réalité il reste des ressources occupées et tu ne peux plus démonter le montage fuse sous-jacent. Le bug est identique que ce soit 1fichierfs ou d'autres choses comme encfs, curlftpfs, etc...
Par contre si le montage est fait en ligne de commande :

sudo mount -o ro,loop fichier_iso point_montage

, une fois le montage démonté aussi en ligne de commande, il est possible de libérer le montage fuse.

Mais si tu étais tombé dans ce "bug", la durée du refresh ne fait aucune différence, dans tous les cas ça "bloque" !..

Dernière modification par Zakhar (Le 10/11/2019, à 15:27)

Zakhar · Le 17/11/2019, à 18:17

ploopie a écrit :

Merci à toi, je suis OFF toute cette semaine qui viens mais je teste cela dès mon retour
PS: je te laisse aussi un petit log dans mon syslog juste pour avoir ton feedback, mais j’imagine que c’est un ratelimit coté 1fichier?
Nov  3 00:34:59 host 1fichierfs: [1fichierfs  6310.019] ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/download/get_token.cgi` name=`https://1fichier.com/?itrq69j0bv7wk4`.
Nov  3 00:34:59 host 1fichierfs: [1fichierfs  6310.019] ERROR: http_code 403 on get_token json resp.:`{"status":"KO","message":"Excess slots #897"}` for https://1fichier.com/?itrq69j0bv7wk4
Bonne vacances à moi

La version en test -1.5.4- (déjà sur le GitLab) devrait être bien plus résistante à ce genre d'erreur de l'API.

Pour la suite, le write va être implémenté !

En y regardant à deux fois, en réalité on peut utiliser ftp, ce qui rend les choses infiniment plus simples dans la philosophie de 1fichierfs.
Cependant, à cause du process de publication, le fichier uploadé sera en l'état EBUSY jusqu'à ce qu'il soit arrivé dans son répertoire cible.
A noter que le process de publication par FTP prend 5 minutes + un temps supplémentaire par gigaoctet du fichier (temps de copie physique).

... un peu de patience pour ce "write"... y'a quand même du boulot !

[Edit] Modification en conséquence du pavé "Limitations" du post #1. La seule limitation restante sur un grand nombre de petits fichiers étant la performance due à la latence (100 fois plus qu'un disque rotatif, et 10 000 fois plus qu'un SSD !)

Dernière modification par Zakhar (Le 17/11/2019, à 18:54)

Zakhar · Le 19/11/2019, à 19:39

Alternatives :
Il existe une alternative à 1fichierfs, c'est très bien fait et rapide à prendre en main : rclone.

Comparatif
Versions comparées : rclone 1.5.0 et 1fichierfs 1.5.4 (sur le GitLab, packaging fin de semaine).

Avantages de rclone

Fonctionne aussi sur Mac et Windows (1fichierfs pourrait fonctionner sans trop d'effort sur Mac, sur Windows natif oubliez... ou alors via WSL version 2).
Compatible avec plein d'autres stockages en ligne
Possède déjà la fonction écriture intégrée, y compris modification de fichier (via écriture sur un support local... il n'y a pas de mystère !).

Avantages de 1fichierfs

Efficacité (*) en copie séquentielle : 5 fois plus efficace ! (peut-être la différence entre Go et C ?!)

Sur mon PC du bureau :

$ pv 1fichier/fichier_de_10Go >/dev/null
 481MiO 0:00:17 [32,2MiB/s] [=====>                                                                                                                                                                ]  4% ETA 0:05:38
$ pv ~/1fichier/fichier_de_10Go >/dev/null
 557MiO 0:00:06 [ 111MiB/s] [=======>                                                                                                                                                              ]  5% ETA 0:01:42

Et encore la limitation de 1fichierfs provient de la vitesse de la fibre/ethernet (1Gbps), en effet, le process rclone est à 100% du CPU, tandis que 1fichierfs a encore de la marge à 60% de CPU. Estimation au total : facteur 5
Cela dit, un flux à 30Mb/s avec rclone, c'est largement suffisant pour regarder la vidéo de Tonton Jules en super HD !..

rclone n'utilise pas l'API de download, mais le bon vieux redirect. Cela fonctionne, et c'est même plus universel, mais encore une fois donne un malus de performance très sensible sur une série de petits fichiers. Cela signifie cependant que rclone ne fonctionne pas si vous n'utilisez pas la fonction "identification réseau" de 1fichier (ou que par exemple vous n'avez pas d'IP fixe : certains opérateurs).
rclone bugge quand on a des partages reçus (problème signalé par par Jaxx21 et corrigé depuis un moment sur 1fichierfs, merci aux utilisateurs de 1fichierfs qui signalent des problèmes donc !)
La fonction écriture de rclone nécessite de l'espace de stockage local.
Pour Ubuntu, 1fichierfs propose les .deb sur un ppa, ce qui permet d'avoir la mise à jour en même temps que le reste de votre système.
1fichierfs a des statistiques live, c'est joli, un peu comme top, ça bouge et ça fait classe (même si ce n'est pas une fonction essentielle, Jaxx21 a l'air d'apprécier autant que moi !).
rclone ne s'installe pas en service, il reste au premier plan comme si on avait utilisé l'option "-f". C'est sans doute une limitation due à la volonté de servir W$ aussi. Ce n'est pas dramatique mais peut s'avérer gênant.
pour éviter le syndrome des drivers naïfs qui lisent bloc par bloc (performance inutilisable en https !) rclone lit par blocs de 128Mo (par défaut) tandis que 1fichierfs utilise si besoin un buffer d'avance de 128Ko. Avec rclone, cela peut poser des problèmes de performance/inefficacité si la lecture n'est pas vraiment séquentielle. A contrario, si votre ligne est instable, 1fichierfs ne "bufferise" pas car on considère que c'est à l'application cliente de le faire au besoin (comme Kodi/VLC le prévoient par exemple... donc ne pas refaire ce qui existe déjà).

Egalité

les deux outils peuvent monter un "path" au lieu de tout le stockage. Merci à Ploopie qui en a fait la demande !
prise en main aussi simple, la commande minimale pour rclone est un peu plus longue, mais rclone a un outil pour stocker la clé d'API (pas décisif quand on est habitué à un éditeur de texte !)

Commentaires
A noter que sur la fonction écriture, il n'y a guère de mystère. Le web n'a pas vraiment été fait à la base pour faciliter la publication (écrire), mais pour aller chercher des informations (lire) : page web, fichiers à télécharger, etc...
Avant les réseaux sociaux et ce qu'on appelle le "Web 2.0", publier des informations sur le web restait une affaire de spécialiste !..
La partie écriture dans le web classique se résume à un upload simple d'un fichier. Ca date de html 3.2 (+ de 20 ans !) et nécessite de savoir la taille du fichier à l'avance. Dans le cas de 1fichierfs/rclone, il faut donc écrire d'abord le fichier en local avant de l'uploader... juste pour savoir sa taille !..
rclone a un système de cache local très bien fait et très malin, avec plusieurs niveaux possible, mais avec l'inconvénient d'avoir besoin de stockage local.
Dans la version actuelle de 1fichierfs, j'utilise un script externe (je ne l'ai pas publié car il est un peu "en dur" pas trop "user friendly") qui en réalité fait exactement cela : on copie sur un répertoire local (transparent avec un montage "union") et ensuite une fois le/les fichiers copiés, le même script upload ce qui a été copié.

La version écriture envisagée de 1fichierfs ne nécessitera pas d'espace local. Elle va utiliser ftp, qui n'a pas besoin de connaissance a priori de la taille du fichier. Elle sera par contre limitée par les fonctionnalités de FTP, c'est à dire uniquement écrire un fichier non existant, et seulement en séquentiel (avec tolérance sur quelques Ko). C'est de toute façon l'usage principal pour des outils "cloud storage" comme 1fichier : on réalise des "sauvegardes" par copie d'un fichier (ou équivalent comme rsync).
Cela interdit donc des types d'usage comme se servir de 1fichier pour télécharger du torrent(*)... ce ne serait de toute façon pas adapté en performance, car on tombe sur la limitation petits fichiers/non séquentiel expliquée plus haut.
rclone le permettrait en "trichant", puisque c'est via un stockage local !.. La même fonction est bien sûr toujours réalisable en faisant un montage en union sur 1fichierfs si l'idée était d'utiliser votre stockage local !

(*) Remarque, vous pouvez très bien stocker le torrent à 100% sur 1fichier et le "seeder"... là ça fonctionnerait, mais encore une fois avec une mauvaise performance car l'essentiel des accès sont non séquentiels.

(*) Efficacité et performance : ne pas confondre ! L'efficacité est la vraie mesure. Ce sont les ressources nécessaire à accomplir une tâche. La performance est le temps que cela prendra à accomplir la tâche. Comme il y a toujours un "goulot d'étranglement" (maillon faible) dans cette tâche, c'est lui qui déterminera la performance en réalité. Si on prend en exemple le téléchargement d'un fichier, il est tout à fait possible que vous ne notiez pas du tout d'écart de "performance" entre rclone et 1fichierfs, bien que ce dernier soit 5 fois plus efficace en CPU. En effet, si le facteur limitant est la bande passante de votre liaison ADSL/Fibre, il est possible que le temps de téléchargement soit identique, c'est juste que dans un cas le CPU tournera à 80% et dans l'autre cas à 16%. La différence se verrait alors si les CPU de la machine étaient surchargés d'autres tâches car alors le CPU deviendrait le facteur limitant.

Conclusions :
- Si vous utilisez Ubuntu, n'avez pas d'autre cloud storage que 1fichier, si vous avez un opérateur qui ne vous donne pas d'IP fixe, avez besoin d'un peu de performance (ou machine à faible puissance comme un RPi 3), et n'avez pas des besoins super fréquents d'écriture ==> 1fichierfs
- Par contre si vous utilisez aussi Mac et W$, avez également d'autres "cloud storage", votre machine est suffisamment costaud pour encaisser la charge nécessaire selon le flux souhaité, ou vous avez besoin d'écrire souvent ou de modifier des fichiers existants et pour cela disposez d'espace disque local à dédier, et que vous avez une IP fixe ==> rclone

Dernière modification par Zakhar (Le 22/11/2019, à 15:12)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#176 Le 21/10/2019, à 18:20

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

#177 Le 22/10/2019, à 08:41

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

#178 Le 22/10/2019, à 15:25

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

#179 Le 24/10/2019, à 09:18

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

#180 Le 24/10/2019, à 09:20

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

#181 Le 27/10/2019, à 17:37

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

#182 Le 27/10/2019, à 18:12

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

#183 Le 28/10/2019, à 13:36

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

#184 Le 28/10/2019, à 18:19

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

#185 Le 28/10/2019, à 19:02

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

#186 Le 28/10/2019, à 21:03

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

#187 Le 29/10/2019, à 21:41

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

#188 Le 29/10/2019, à 21:55

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

#189 Le 29/10/2019, à 22:32

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

#190 Le 30/10/2019, à 07:42

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

#191 Le 30/10/2019, à 11:38

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

#192 Le 30/10/2019, à 17:36

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

#193 Le 30/10/2019, à 19:49

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

#194 Le 03/11/2019, à 00:42

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

#195 Le 04/11/2019, à 00:36

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

#196 Le 05/11/2019, à 08:52

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

#197 Le 10/11/2019, à 14:49

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

#198 Le 10/11/2019, à 15:02

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

#199 Le 17/11/2019, à 18:17

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

#200 Le 19/11/2019, à 19:39

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

Pied de page des forums