Ubuntu-fr

Zakhar

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

Condamné en correctionnel, l'hebergeur 1fichier va faire appel.

Bon, en tout cas j'espère que ça ne va pas nous tuer notre excellent service de sauvegarde en ligne à un prix imbattable !..

Au moins 1fichierfs montre que ce genre de service est un outil. Comme toujours, ce n'est pas l'outil lui-même qui est illégal, mais l'usage que certains en font.

Comme le disent aussi les commentaires de l'article, il ne serait pas étonnant que tous les services de stockage en ligne, y compris ceux ayant pignon sur rue, hébergent plus ou moins de "fichiers partagés".

Dernière modification par Zakhar (Le 26/04/2021, à 21:24)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

lynn

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

Ben ça alors c'est surprenant ; des fichiers partagés illégalement sur 1fichier.com... qui l'eût cru !

---

«C'est pas parce qu'ils sont nombreux à avoir tort qu'ils ont raison!»

Coluche

Zakhar

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

Je suis sûr qu'il y en a plein aussi qui sont partagés avec GDrive ou Onedrive, mais personne ne s'en émeut.

Il est bien parti le Cloud Européen avec les "z'ayant-droit-plein-de-soupe-mais-qui-en-veulent-toujours-plus" qui vont le détruire avant qu'il naisse. Pauvre Europe !..

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

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Zakhar

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

Brèves nouvelles.

Le "nouveau moteur de lecture" a bien avancé, il est déjà bien fonctionnel sur mes tests personnels.

Avantages : il ne nécessite pas de "threads séparés" pour la lecture, et il n'y a donc plus de limites à "4 threads de lecture" qui pouvaient donner des performances dégradées en cas de lectures en parallèle de beaucoup de fichiers. La limite à 4 "streams de lecture" est désormais par fichier, et se fait sans besoin de "threads séparés". Au final ça devrait prendre moins de ressources et donc être dans certains cas plus performant.

Inconvénients : c'est encore pour le moment "en travaux", même si ça marche déjà fort bien. Certaines choses ne sont pas encore ré-implémentées, notamment les statistiques qui vont changer assez radicalement.

Pour tester, pour les téméraires, ou si vous avez besoin de la fonctionnalité "beaucoup de lectures en parallèle", vous pouvez compiler directement depuis le Gitlab à partir de la branche "new_read_engine".

Evolutions : l'écriture suivra ensuite le même procédé (c'est plus simple en réalité pour l'écriture qui est moins "parallélisée") et la limite de 4 fichiers écrits en parallèle sera levée. J'ai commencé par la lecture, car si d'ici que je m'attaque à l'écriture, la Team 1fichier a mis son nouveau système envisagé (http pour les abonnés en écriture), je ferai d'une pierre deux coups.

Notez que la levée des limitations locales ne permet pas d'aller au delà des limites imposées par le service 1fichier.com (qui sont autour de 50 flux par IP en lecture... mais que je n'ai jamais atteintes !), et non plus, cela ne lève pas la limitation de la bande passante de votre connexion à internet !

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

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Zakhar

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

La mise au point de "nouveau moteur" de lecture m'a fait rendre compte que 1fichierfs est sous-optimisé pour des commandes de base comme cp (la copie simple).

Cette commande étant probablement une des plus ancienne de Unix-GNU/Linux, elle fait un truc qui est sans doute devenu totalement inutile avec les kernels moderne : de la copie "en parallèle" sur deux threads. Couplé avec le "read-ahead" du kernel, cela veut dire qu'on peut se retrouver à avoir 4 requêtes en cours sur un même "stream"... mais surtout que ces 4 requêtes peuvent arriver dans un désordre quelconque : les joies du parallélisme !
Or si j'avais bien prévu la gestion du "read-ahead" avec 2 requêtes inversées, ça ne va pas jusqu'à 4 !..

Cela se voit actuellement si vous faites un simple "cp" sur un gros fichier (par exemple pour récupérer sur vos disque locaux une "sauvegarde"), vous allez voir, en affichant les statistiques, que la lecture se fait bien séquentiellement, mais que de temps en temps, vous avez "de petits blocs" qui sont lus isolément. Résultat : pas totalement "optimisé" !..

Je travaille sur le "nouveau moteur" à gommer ça.

En attendant, au lieu d'utiliser "cp", je vous recommande l'excellent pv qui a aussi l'avantage de vous afficher une belle jauge de progression du transfert : avancement, vitesse, temps restant estimé...

La copie "à la souris", via "Nautilus" ne semble pas poser le même problème et se fait correctement.

Je testerai aussi le comportement face à rsync, qui est un outil "classique".

Enfin, toutes ces optimisations vont donner du sens à rajouter dans le "moteur" la lecture "splice" qui est sensée alléger la charge CPU et donc à défaut d'aller plus vite (c'est sans doute limité par votre fibre/ADSL ou CPU pour les flux chiffrés), consommera moins de ressources... donc quand même meilleures performance en cas de machine très chargée.

Je "benchmark" aussi avec une version de transfert "sans curl", parce que curl se comporte de façon qui me semble vraiment peu optimale quand on utilise les "pauses", ce que fait le nouvel algorithme. Je verrai si ça fait une différence visible, au moins en CPU, quand tout sera au point et donc vraiment comparable.

Encore un peu de patience donc pour les "améliorations".

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

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

NOLAK

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

Bonjour Zakhar,

Jusqu'à maintenant aucun problème mais aujourd'hui j'ai un souci.
Peux-tu m'aider ? Il impossible pour moi de remonter 1fichier, j'ai l'erreur la :

 ERROR: Ignoring: error 28 on curl_easy_perform url=`https://api.1fichier.com/v1/folder/ls.cgi` name=`/`.

Merci d'avance de ton aide.

J'ai finalement ma réponse :

Coupure totale du service cette nuit, déplacement des principaux serveurs.

Dernière modification par NOLAK (Le 26/08/2021, à 10:17)

Zakhar

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

Voila Nolak !

Effectivement, 1fichier.com a fait un grand changement d'architecture matérielle et logicielle. Le service a donc été coupé partiellement les jours précédents (certains machines "cassées") et pendant presque une journée le jour du changement.

Par conséquent, effectivement 1fichierfs ne se montait plus au démarrage... mais le site 1fichier.com ne répondait pas non plus, ce qui peut donner la puce à l'oreille que ça ne venait pas de 1fichiefs.

(Et désolé de la réponse tardive, je n'ai pas eu l'e-mail de "suivi", mais puisque c'est résolu depuis que 1fichier.com fonctionne à nouveau, il n'y a pas de mal !)

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

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

liberty_linux

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

Bonjour,
J'aime beaucoup le projet 1fichierfs! J'essayerai de le préparer pour le mettre sur le AUR de archlinux, car j'utilise plusieurs OS au quotidien. Pourrais-tu préciser la procédure pour compiler 1fichierfs et l'installer ?
Aussi, je me posais la questions, c'est parfois long d'attendre le traitement par 1fichier en FTP, serait-il possible d'implémenter une autre façon via le upload.cgi de l'API ?

Encore merci pour ton travail, c'est très pratique comme solution!

Zakhar

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

Bonjour liberty_linux et merci pour tes encouragements.

La compilation est fort simple.
Il te faut tout d'abord les deux prérequis : fuse et curl

Pour Ubuntu on fait :

sudo apt install libfuse-dev libcurl4-openssl-dev

libcurl vient avec plusieurs ssl backends. Si ta version de openssl est supérieure à 1.1.0, il faut prendre celui indiqué dans la commande au dessus. Sinon il faut prendre gnutls pour des raisons de comparabilité multithread.

Bien sûr sur Arch, ce n'est pas apt le logiciel de package, je te laisse adapter !

Ensuite c'est très simple dans le répertoire principal du projet tu as un make, donc

make -B 1fichierfs

Cela suppose que tu as les outils standard make et gcc.. mais c'est tellement la base !..

Ensuite tu peux regarder ce que fait le package debian, il se contente de faire un

make install

Ce qui va copier l'exécutable dans /usr/bin, et les manuels au bon endroit : /usr/share/man/man1/ pour l'anglais et /usr/share/man/fr/man1/ pour le français.
En fait il y a sans doute un moyen pour "livrer" un man de façon plus "propre" que passer par le make, mais j'ai pas trouvé la documentation qui va bien... c'est une des difficultés du packaging sur Ubuntu/Debian, les docs sont merdiques et pas à jour... quand elle existent !

Pour le ftp hélas non il n'y a rien à faire pour le moment.
L'upload en http n'est pas possible car il faudrait connaître à l'avance la taille du fichier à uploader avec le fonctionnement actuel, et ce n'est pas une chose envisageable pour 1fichierfs parce que simplement fuse ne fonctionne pas ainsi !

On pourrait certes faire un code pour les "petits fichiers", genre moins de 64k, mais ça ferait tout un bout de code pour sans doute pas grand chose.

La vraie solution est dans les mains de la team 1fichier avec qui je parle de temps en temps.
Ils m'ont fait saliver sur la possibilité que les "premium" (c'est à dire nous les clients payants !) aient un upload http qui supporte le "chunked encoding".
Si c'est le cas, je peux remplacer presque du jour au lendemain l'upload en ftp par un upload en http-chunked-encoded, gagner les 5 minutes d'attente dues au FTP, et supprimer pas mal de code de la tâche de fond qui fait des choses en automatique.
Aussi tout le code de "reprise" devient totalement inutile et peut être simplement supprimé !

Cependant, cela ne supprimera pas la phase de "vérification" pendant laquelle le driver continuera de répondre que le fichier est occupé, puisque le serveur interdit la lecture tant que la vérification n'est pas finie.
Cette phase prend environ 15 secondes par giga, donc par exemple un fichier de 10Go est "indisponible" environ 2min 30.
Il est possible (et même plus que vraisemblable) qu'il y ait aussi en http, comme en ftp, un phase de "copie vers le storage". En fait quand on upload, on ne met pas directement les fichiers dans le "storage" mais dans un tampon intermédiaire, puis ensuite ils sont copiés vers le storage et détruits du tampon quand la copie est Ok. Cette phase prend à peu près le même temps que la phase "vérification".
Mais c'est sûr on y gagne par rapport à maintenant au moins les 5 minutes FTP...

Bref j'attends qu'1fichier fournisse cette "évolution", mais c'est très bas dans la liste de leurs priorités hélas !

Par contre si tu viens de copier un gros fichier via 1fichierfs, tu peux couper ton PC, et la fois d'après que tu l'allumeras, le fameux code de reprise se chargera de finir le travail en déplaçant le fichier uploadé au bon endroit. Evidemment si tu attends la fichier sur l'interface web, il ne faut pas faire ça. En effet 1fichierfs upload tous ses fichiers dans le répertoire .upload-1fichierfs situé à la racine de ton compte, et les fichiers n'ont pas leur "vrai" nom. Tout ça c'est pour le mécanisme de reprise !

En attendant, j'ai toujours en perspective le "nettoyage" du "moteur" de lecture. Le "moteur" actuel est un peu bancal même s'il marche globalement bien. J'ai des "race conditions" connues à l'ouverture simultanée de plusieurs fichiers qui peuvent donner des erreurs de lecture. Si cela arrive, il faut juste redémarrer le driver. C'est tellement rare que je n'ose toucher le code de faire plus de mal que de bien, et j'attends plutôt la "version propre" en travaux.
Le "moteur" de lecture actuel n'a aussi "pas assez de buffers" par rapport à ce que fait Linux sur une "copie séquentielle". En réalité, le kernel et les outils GNU travaillent parfois avec jusqu'à 4 buffers de 128k d'avance ou de retard. Il faut donc 3 buffers de 128k de stockage, si on veut qu'une copie séquentielle soit bien aussi séquentielle pour 1fichierfs. Actuellement le moteur ne travaille qu'avec un seul buffer de 128k. Cela ne produit pas d'erreur, mais juste parfois une "sous-optimisation" parce que le moteur devra faire plusieurs requêtes (range) au lieu d'une seule qui aurait suffi dans le code idéal !
J'avais testé une voie pour le ré-écrire, mais cette voie s'avère être un impasse. La "bonne architecture" est ce qui est fait actuellement, c'est à dire lecture via un thread "reader"... il faut juste que je le rendre "propre" et généralisable à d'autres APIs ou par exemple au générique astreamfs qui fonctionne sur le simple http(s).

Dernière modification par Zakhar (Le 15/10/2021, à 23:06)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

liberty_linux

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

Bonjour Zakhar,

Tout d'abord merci pour ta réponse rapide! Tes explications sont très claires. Merci encore de prendre de ton temps pour nous faire ce beau projet.
J'ai bien saisi les problèmes du coup ça attendra, de toute façon j'ai déjà une petite idée, je partagerai mes fichiers en http ou ftp et je ferai un script avec le remote upload de l'API pour répondre à un besoin très précis pour moi. Ta solution de write est déjà suffisante pour moi.

Par ailleurs j'ai une petite question.... Quand je déplace un dossier depuis la console 1fichier.com, cela ne se met pas à jour depuis 1fichierfs...
Il faut que je redémarre le driver pour forcer l'update du dossier et voir mon fichier. Aurais-tu une manière de "forcer" un dossier à aller redemander l'API ?

Merci.

Zakhar

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

Pour la question, bien sûr, tout est dans le "man" ou dans l'aide en plus simplifié

$ 1fichierfs --help
(...)
    --refresh-file=filename
    --refresh-hidden
    --refresh-time=M  These parameters control how the directory tree
                      is refreshed from the server.
                      By default, no refresh is done.
                      refresh-file shows an empty file on the root of the
                      mount. Opening, this file triggers a refresh.
                      If refresh-hidden is specified, the file will no be
                      shown. Trying to open it will return 'no such file'
                      but will still trigger a refresh.
                      refresh-time specifies a timer in minutes after which
                      a refresh will be done.


$ man 1fichierfs
(...)
       --refresh-file=nom_du_fichier

       --refresh-hidden

       --refresh-time=M
              Ces paramètres contrôlent comment l'arborescence complète est rafraîchie depuis le serveur.

              Indépendamment de ces trois options, après une opération d'écriture les répertoires concernés (destinations de renommage ou lien dur, ...) sont toujours rafraîchis. Un rafraîchissement global
              est fait systématiquement si un fichier qui était sensé être présent a été effacé (HTTP 404). Cela peut survenir si le fichier a été effacé depuis l'interface web pendant que 1fichierfs fonc‐
              tionnait.

              Si  la  lecture d'un fichier retourne une errer, les ouvertures suivantes du même fichier échoueront avec 'accès refusé' jusqu'à ce qu'un rafraîchissement soit fait (sur n'importe quel réper‐
              toire). Après ce rafraîchissement, l'utilisateur peut essayer à nouveau de lire le fichier.

              --refresh-file affiche un fichier vide à la racine du point_de_montage.
              Ouvrir ce fichier déclenche le rafraîchissement.
              Si nom_du_fichier est masqué par un fichier ou un répertoire existant portant le même nom à la racine du compte 1fichier.com, un avertissement est envoyé, et l'option --refresh-file est igno‐
              rée aussi longtemps que le fichier ou répertoire qui masque nom_du_fichier n'est pas supprimé ou renommé.

              Avec --refresh-hidden, le fichier spécifié par l'option --refresh-file ne sera pas affiché.
              Essayer de l'ouvrir retournera 'fichier inexistant' mais déclenchera également le rafraîchissement.
              Cette option est mieux adaptée à un rafraîchissement via la ligne de commande.

              Sauf s'il est masqué, le --refresh-file, qu'il soit caché (--refresh-hidden) ou pas, est protégé contre la suppression, le lien, le renommage et l'écrasement en tant que destination d'un lien
              ou renommage. De telles opérations retourneront : accès refusé.

              --refresh-time  spécifie un temps M, en minutes, après lequel les entrées de répertoires en cache seront oubliées. Une valeur de 0 signifie pas de --refresh-time.

Donc en faisant la manipulation que tu indiques ou n'importe quelle autre (par exemple 2 instances de 1fichierfs indépendantes), tu as "désynchronisé" la cache de 1fichierfs.

Les options par défaut (sans aucun autre paramètre que la clé d'API) ne prévoient pas de "rafraîchissement" (sauf cas documenté dans le "man"). L'arborescence lue est réputée éternellement valide tant que tu ne manipules que via 1fichierfs.
Par contre les 3 options ci-dessus font un recyclage de la cache ainsi qu'expliqué par le "man" en français ou plus succinctement par l'aide en anglais.

A noter que 1fichierfs ne lit que les répertoires que tu accèdes, et non pas toute ton arborescence. Si le timer du refresh-time est écoulé, la cache est invalidée, mais 1fichierfs ne fera aucune requête d'API tant que tu ne fais pas un nouvel accès. Donc même avec un refresh-time à 1 (une minute) les accès aux répertoires ne sont faits qu'au besoin.
La seule exception à cela est le répertoire racine qui est lu au démarrage... c'est en fait pour s'assurer qu'on peut bien accéder : internet opérationnel, 1fichier.com pas en panne, clé d'API et paramètres de sécurité du compte corrects, etc... Si 1fichierfs ne parvient pas à lire le répertoire racine (dans le temps imparti), le montage ne se fait pas et un message est indiqué sur la console (car on n'est pas encore en tâche de fond).
Il y a un cas d'usage de "refresh-time à 1", j'ai un "client" de 1fichierfs qui a toujours un compte vide, et quand il a besoin, il y pose un fichier (peut-être le film de vacances de tonton Hector aux Baléares) et utilise alors le fichier via 1fichierfs. En quelque sorte un streaming. Comme le compte est vide sauf le fichier qu'on vient de mettre, dans ce cas le refresh-time à 1 fait du sens pour qu'on ne tarde pas trop à voir le fichier qu'on vient de poser sur le compte de façon automatique.
Sinon je recommande une valeur plus élevée pour ne pas nuire à la performance. Personnellement j'ai un time à 20 (20 minutes), plus un "fichier refresh" non caché pour les cas où je veux "forcer le rafraîchissement".

Oui effectivement, le "remote upload" aurait aussi été une façon d'uploader, mais comme on serait alors rentré dans des complexités de ports entrant à ouvrir, j'ai préféré ne pas aller dans cette voie.

Malheureusement le "upload pour premium" n'est pas tout de suite pour demain à mon dernier échange avec la team 1fichier:

Bonjour,

> - Avez vous des nouvelles de "l'upload pour premium" ?
> J'ai bien noté cependant que c'est "basse priorité" de votre côté ! ?

Ce n'est pas prévu pour le moment....

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

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

liberty_linux

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

Merci pour ta réponse, j'ai bien compris le fonctionnement du cache et du refresh...
Et tant pis pour l'upload premium, on déjà ce qu'il faut pour le moment

Zakhar

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

Voila ! S'il te semble qu'il manque un truc ou si tu vois des bugs n'hésites pas à signaler.

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

flanfrit

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

Bonjour Zakhar

Je ne sais pas tu as vu mais j'ai créé une issue sur ton gitlab pour te demander si il serait envisageable de modifier ton outil pour permettre de monter un volume à partir d'un dossier contenant des fichiers *.strm.
En fait Plex ne gère pas bien les fichiers strm contrairement à emby. Un fichier strm est un fichier texte contenant simplement une URL à l'intérieur.
Je cherche donc à monter un dossier ou Plex verrait des fichiers classiques MKV par exemple mais qui en fait pointerai vers le lien contenu dans le fichier strm du même nom.
Pourrais-tu me dire si cela serait possible avec ton outil?

Merci par avance

Zakhar

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

Bonjour flanfrit,

Tu fais bien de mettre un mot ici, parce que je "commit" moins depuis que 1fichierfs dispose de toutes les fonctionnalités possibles, et donc je n'avais pas encore vu ton "issue" (disons plutôt "whishlist" !) sur GitLab.

Donc si je comprends bien ça concerne le driver "générique" astreamfs et pas directement 1fichierfs (encore que ça pourrait servir dans les 2 cas puisque l'un est issu de l'autre).

En fait la demande a l'air de ressembler à ce qu'on fait pour les "redirections" (http 301, 302, etc...) mais simplement, au lieu de suivre le "Header", il faudrait aller chercher le lien dans le contenu du fichier.
Ai-je bien résumé ?

En pratique tu peux déjà "contourner le problème", comme je le faisais avec un script + astreamfs avant d'avoir développé 1fichierfs. Ce que le script faisait, c'est simplement aller lire (technique "web scraping") le compte 1fichier.com et préparait tous les arguments pour que astreamfs soit content.
Donc là tu peux faire pareil en t'inspirant du script 1fichier qui est sur le Gitlab:
- Script qui lit le contenu de tous les fichiers .strm et prépare les arguments pour astreamfs.

Je retiens cependant ton idée, mais je vais sans-doute la généraliser pour les deux "drivers" pour gérer les "lien symboliques".
A ce jour 1fichierfs gère les liens "en dur" (non symbolique), c'est ce que 1fichier.com appelle une "copie de fichier". En réalité ça ne copie pas vraiment les octets, ça crée juste un deuxième lien qui pointe vers le même fichier... exactement le principe des liens (en dur) sur Linux. Par contre il n'existe pas de possibilité de faire des "liens symboliques" qui sur Linux sont juste des fichiers spéciaux contenant le chemin du fichier lié.

astreamfs étant "générique" ne gère rien de tout ça... et aussi ça fait un moment que je n'y ai plus touché... je ne sais même plus s'il se compile encore sur la dernière version de la branche "master" !..

Pour gérer ce genre de "liens symboliques", il faut se poser quelques questions de "design" sur la fonctionnalités :
- Comment je sais qu'un fichier (URL) est en fait un lien symbolique et pas un "vrai fichier" ?
==> possibilités : par répertoire, "pattern" sur le nom du fichier (par ex. extension), paramétrage -avec astreamfs on pourrait, pas avec 1fichiefs-, etc..
- Que contient exactement le fichier pour nous donner les informations nécessaires ?
==> Obligatoire: URL, facultatif : nom du fichier cible (ou lien complet), date/heures, taille
A noter que seule l'URL est obligatoire, le nom du fichier on peut avoir une valeur par défaut à partir du lien (ce que fait astreamfs), et les tailles/dates sont récupérées par interrogation de l'URL si non fournies.

Pour astreamfs (ça n'aurait pas trop de sens pour 1fichierfs) ou pourrait aussi rajouter une option pour que le fichier cible remplace le lien (comme une redirection). Ce qui serait d'ailleurs sans doute le fonctionnement par défaut qui fait plus de sens pour ce driver "générique".

Dis-moi ce que tu en penses...

Si c'est bien pour astreamfs, continuons plutôt la conversation sur le Gitlab pour le "design" du truc, et pour éviter d'interférer sur ce fil davantage destiné à 1fichierfs.

Sinon en résumé... bien sûr que c'est possible (tout est possible... faut juste le développer !).
- ça ne sera cependant pas très performant : il faut aller ouvrir les fichiers, ce qui est plus long que regarder des headers
- on est dans l'open source n'est-ce pas... donc tu peux même développer la fonction et faire un "pull request"... façon polie de dire que ça ne sera sans doute pas fait demain !
- la solution temporaire du script est sans doute idéale. Tu peux faire des choses dans le script que je ne mettrai jamais dans les drivers, par exemple gérer une "cache" des fichiers que tu connais déjà, pour n'ouvrir que les nouveaux. Le but du script, à la fin, est de lancer la commande astreamfs avec "les bons paramètres" pour qu'il te montre les fichiers que tu veux voir, avec les noms que tu souhaites !

[EDIT]
Cela dit, je partais de l'idée que les fichiers de "lien" étaient en ligne... mais s'il sont sur ton serveur où tu as la main, c'est assez simplissime à faire avec un script.

J'ai créé un répertoire de test avec les 2 fichiers tels qu'indiqués dans ton "issue" et voici en une ligne :

$ { echo 'astreamfs '; cat *.strm | sed 'p;s/.*\?file=/--output /'; echo ' mnt' }| tr '\n' ' '
astreamfs  http://host.com?file=111.mkv --output 111.mkv http://host.com?file=222.mkv --output 222.mkv mnt

Tu n'as plus qu'à mettre ce résultat dans une chaîne au lieu de l'afficher, et faire un "eval" pour lancer la commande (oui je sais eval is evil !)

Ce que fait le "one-liner" ci-dessus :
- On affiche "astreamfs" qui est la commande (rajouter aussi les options voulues à cette étape)
- on concatène tous les fichiers .srtm du répertoire
- le 'sed' affiche la ligne et extrait le nom du fichier qu'il affiche derrière un "--output"
- on fait un 'echo' du répertoire où on veut monter
- on termine en enlevant les retours charriot

Et voila le tour est joué avec un script en deux coups de cuillère à pot.

Si les fichiers de lien sont eux même en ligne, il faut en avoir la liste (astreamfs ne peut pas la deviner, contrairement à 1fichierfs !) et c'est à peine plus compliqué. Il faut juste faire une boucle de "curl" pour aller lire chacun des fichiers en ligne au lieu du "cat".

[EDIT 2]
Je t'ai répondu sur gitlab en donnant un "oneliner" pour monter l'équivalent passant avec des liens sur les dernières iso d'Ubuntu, histoire de pouvoir vérifier que cela fonctionne.

Un "oneliner" est un script suffisamment simple pour tenir en une ligne de commande.

Ce qu'il faut adapter (en supposant que tes fichiers soient locaux dans un répertoire), c'est le 'sed' pour qu'il prépare la commande correctement.

En l'occurrence dans mon exemple le lien est "coupé" sans le ?file=... qui ne sert qu'à donner un nom de fichier pour astreamfs
Si le ?file=... est nécessaire pour que le lien fonctionne, c'est une simple adaption du sed, c'est même plus simple c'est ce qui est au dessus.

astreamfs est plus "basique" que 1fichierfs puisqu'il n'a besoin que d'une chose : un serveur web qui sait gérer des "range". Mais aussi il faut souvent lui mâcher le travail, parce qu'il n'existe rien en standard sur le web pour faire des choses basiques comme lister un répertoire !
A ce point de vue, l'utilisation de 1fichierfs est largement plus simple puisque l'API permet précisément cette "normalisation".
En "théorie", tu peux te servir de 1fichierfs avec la commande la plus simple :

1fichierfs point_de_montage

La "magie de l'API" fera le reste.
Bien sûr, c'est la "théorie", en pratique il vaut mieux spécifier aussi la "clé d'API" dans la commande sinon l'utilisateur va devoir la taper à chaque fois... sans se tromper... ce qui n'est pas une mince affaire.

[Information]
Pour information, je suis en train de "rénover" le "moteur de lecture" commun à astreamfs et 1fichierfs.
Le "moteur" actuel fonctionne très bien, mais il y a quelques "race conditions" qui peuvent se manifester en ouvrant plusieurs fichiers "en même temps". Le symptôme est alors que les fichiers retournent des erreurs de lecture, mais heureusement ça ne se manifeste que de façon rarissime. Si cela survient, pas d'autre solution actuelle que d'arrêter et relancer le montage. La bufferisation est aussi limitée, ce qui fait qu'il n'est pas totalement optimisé pour toutes lectures séquentielles. Ce n'est pas dramatique, c'est qu'à certains moment ça va refaire une lecture "range" alors qu'en bufferisant mieux on aurait pu s'en passer.
Le nouveau "moteur" va être mieux écrit et plus général. Par défaut il traitera jusqu'à 32 "streams" en parallèle avec un maximum de 4 par fichier (au lieu de 4 au total à ce jour), et tout ça dans un unique thread.
Je l'écris en premier pour 1fichierfs que j'utilise le plus.
Il sera ensuite porté sur astreamfs, qui du coup va bénéficier du "gadget" d'avoir des statistiques !

Dernière modification par Zakhar (Le 09/11/2021, à 21:17)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

flanfrit

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

Merci beaucoup pour ton aide cela fonctionne bien par contre j'ai encore un souci.
En fait le principe est que mes fichiers STRM pointent vers un endpoint d'une petite appli python sur mon serveur qui prend en paramètre le code d'un fichier uptobox ou 1fichier. Cette appli utilise un compte premium chez le hoster concerné, utilise son API pour obtenir le lien direct de celui-ci et fait une redirection via une réponse 302 vers le lien du fichier récupéré.
En utilisant le lien vers mon endpoint avec un code de fichier uptobox ou 1fichier et en tentant de le monter avec astreamfs, j'obtiens le message "the server does not handle ranges". J'ai tenté de rajouter le header "Accept-Ranges:bytes" dans les header de la réponse 302 mais cela ne fonctionne pas. Le lien direct Uptobox ou 1fichier renvoi bien ce header avec le fichier en attachment.
Est-il possible de faire en sorte que astreamfs prenne les headers du lien après la redirection plutôt que les headers de la redirection du 302 de mon serveur?

Merci

Zakhar

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

Bien sûr flanfrit, c'est déjà prévu et ça marche comme avec curl en ligne de commande.

Désolé astreamfs n'a pas de page de manuel (man), mais toutefois une aide synthétique :

$ astreamfs --help
Usage: astreamfs [options] URL [options] [[URL] [options]]* mountpoint

astreamfs options:
(...)
     -i  --idle-time=T Time (sec) after which a stream will return to idle
                       state if it receives no request. Default: 300s
     -t --keep-location-time
                       Combined with -L option, astreamfs will use the
                       redirected location for the specified time (sec), when
                       a new stream is needed. It can save a lot of overhead
                       in situations where the redirected location is valid
                       for some time.
                       This option has no effect when -L is not specified.
                       Default: --no-keep-location (see below)
                       Both time option: 0 means forever.
        --no-keep-location
                       This is the default and cancels a previous -t.
                       It means always restart from the original URL and never
                       use twice a previous redirect location.

(...)
curl options used by astreamfs (`man curl` for detail):
     -L --location

Tu rajoutes l'option -L (ou --location) au lancement de astreamfs, et si ton développement personnel renvoie correctement un http 302, astreamfs va suivre le lien de redirection.

Le message que tu obtiens est normal si tu n'a pas précisé -L, parce que dans ce cas on ne cherche pas à interpréter les redirections et on suppose que l'URL passée (pointant sur ton propre serveur) est véritablement le fichier à lire, et donc on fait des "range" sur cette URL... Rajouter des "range" sur les URL gérées par ton serveur qui sont en fait des redirections n'arrange effectivement rien puisque astreamfs ne cherche même pas à suivre la redirection si tu ne lui as pas précisé !

Je t'ai montré dans l'aide d'autres paramètres intéressants pour avoir une meilleure performance.

Par exemple, le lien que tu obtiens avec 1fichier.com, via redirection ou API, est valable 30 minutes (je simplifie, il y a des "subtilités" !).
Aussi, il y a un "keepalive" qui maintient une connexion ouverte "un certain temps". Pour 1fichier.com, les connexion TCP sont maintenues 5 minutes, mais au delà d'une minute on observe en réalité des phénomènes bizarres.

Donc pour un lien vers 1fichier, les options que tu veux mettre sont :

-L -l 1740 -i 55

Ces options là sont propres à chaque lien, et propagées par défaut aux liens suivant. C'est à dire que si ton serveur personnel sert aussi pour des fichiers ailleurs que 1fichier.com, tu peux avoir un jeu de paramètres différents pour ces fichiers là.

Exemple:

astreamfs -L -i 55 -l 1740 https://1fichierlink1 https://1fichierlink2  https://uptobox.link3 https://uptobox.link1 -l 3600  https://uptobox.link2

Sur l'exemple ci-dessus, -L (suivre les redirections) s'applique à tous les fichiers, tout comme -i 55 qui demande de garder les connexion 55 secondes (pour être sûr de ne pas dépasser la minute où les choses commencent à être bizarre).

Pour les 3 premiers liens supposés aller vers 1fichier, la redirection sera gardée 1740 secondes (soit 29 minutes), et pour les deux derniers liens réputé aller vers uptobox, la redirection sera gardée 3600 secondes (1 heure).

Le fait de garder la redirection est très intéressant pour la performance sinon à chaque fois que astreamfs doit ouvrir un nouveau "range", ce qui prend déjà du temps parce qu'il doit refaire une requête avec 1fichier, uptobox, etc... il devrait en plus avant de faire ça, interroger ton serveur local lequel va refaire un accès d'API... ce qui sans doute doublerait ou triplerait (ou plus !) le temps de chaque ouverture de nouveau "range".

Le keepalive est encore une meilleure optimisation, et c'est pourquoi il est de toute façon par défaut. Si par exemple tu lis un film stocké sur le cloud avec VLC (ou Plex, ou peu importe !) et que tu fais une pause, la lecture va s'interrompre le temps de la pause, mais pour autant la connexion TCP avec le serveur est toujours ouverte. Celle-ci ne sera fermée qu'au delà du délai spécifié par -i, ou si le serveur ferme la connexion de son côté. Donc en l'occurrence, si l'utilisateur avait fait une pause dans le visionnage de 30 secondes, astreamfs ne va même pas avoir besoin d'ouvrir un nouveau "range" pour la suite de la lecture du film, il continuera sur la même connexion TCP (socket) qui est restée ouverte le temps de la pause.

Donc en résumé, astreamfs est bien plus puissant et versatile que 1fichierfs dans ce qu'il permet de faire. Le revers de la médaille est qu'il faut complètement lui "mâcher le travail" en lui préparant une liste de paramètres détaillée, chose qui est rendue non nécessaire pour 1fichierfs via l'API qui permet de lister les répertoires, les noms, tailles et dates des fichiers. Les paramètres "location", "keepalive", etc... sont gérés "en dur" dans 1fichierfs puisqu'ils ne concernent que ce service là, pas besoin de complexifier.

Dernière modification par Zakhar (Le 27/11/2021, à 11:50)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

flanfrit

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

Merci beaucoup pour ta réponse.
Entre temps j'avais réussi a faire fonctionner astreamfs avec mon serveur en modifiant mon endpoint pour qu'il agisse comme un proxy. Il récupère le range et le renvoi directement sous forme de range.
Astreamfs ne me dit donc plus que le serveur ne gère pas les range, vu que j'en renvoi à présent. Je testerai tout de même avec ma version d'avant qui faisait une redirection et le paramètre L.
J'ai cependant un autre problème. J'ai créé un folder /mnt/test avec mon user root. Ensuite je lance la commande astreanfs avec sudo. Je vois bien les fichiers dans le dossier si je suis en root. Par contre j'ai que des point d'interrogation sur ce folder si je fais un ls -lh sur /mnt avec mon user normal. Je n'ai non plus pas accès au contenu du dossier. Si je fais l'inverse, je ne vois rien avec le user root.
Du coup dans plex je n'arrive pas à ajouter ce folder en librairie parce qu'il semble ne pas le voir.
Je ne suis pas un grand expert avec les permissions linux mais peut être que tu pourrais m'aider?

Zakhar

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

Ah oui, ça c'est pas propre à astreamfs, mais à fuse lui-même !

Un montage fuse, pour des raisons de sécurité, est conçu pour être fait par l'utilisateur en session, et sans élévation de privilège (sudo/root). C'est donc un des rares cas où l'utilisateur peut "monter" un truc sans privilège.
Les fichiers exposés par le driver fuse ainsi monté sont visibles sans restriction de l'utilisateur qui a fait le montage, mais sont inaccessible pour tout autre utilisateur, y compris root !

Donc un cas particulier où l'utilisateur a plus de droits que root.

Même quand on connaît bien "les droits linux" (POSIX en réalité), fuse est un peu déroutant. Sans compter que le driver fait aussi "ce qu'il veut" pour les droits, et si tu veux programmer un driver qui ne donne accès qu'aux utilisateurs qui ont un UID divisible par 3 et cacher certains fichiers les jours de pleine lune... c'est totalement possible... et ça sèmerait bien sûr tellement la confusion pour l'utilisateur, qu'évidemment astreamfs ne fait pas de telles choses !

Bien sûr, si on accepte les trous de sécurité : que quelqu'un d'autre que celui qui a fait le montage puisse voir les fichiers qui ont été montés et donc qui ne lui appartiennent pas car ils appartiennent à celui qui a monté, on peut demander à Linux de passer outre.

Pour ce faire il te faut 2 choses :

Modifier (en sudo, et une fois pour toutes) le fichier /etc/fuse.conf pour autoriser la visibilité à d'autres :

$ cat /etc/fuse.conf
# /etc/fuse.conf - Configuration file for Filesystem in Userspace (FUSE)

# Allow non-root users to specify the allow_other or allow_root mount options.
user_allow_other

Surtout ne pas faire le montage en root... ça ne sert à rien à c'est dangereux !.. Il faut bien sûr faire le montage sur un répertoire que ton utilisateur a le droit d'utiliser !
Donc par exemple :

sudo chown "${USER}:${USER}" /mnt/test

avant de faire ton montage sans sudo sur mnt/test

Tu fais le montage simplement avec ton utilisateur en session, mais tu rajoutes l'option

-o allow_other

Cette option "permet" (allow) alors à "un autre" (other) d'accéder aux fichiers ainsi montés.

Si c'est pour Plex, par exemple, il tourne avec son propre utilisateur, et pourra ainsi "voir" les fichiers montés.

Il y a aussi l'alternative -o allow_root, cela autorise seulement 'root' en plus de l'utilisateur courant à voir les fichiers, tandis que allow_other autorise absolument tout le monde (root compris), comme si les fichiers étaient en mode "777" (grand ouvert à tous !).

Bien sûr, faire de ton serveur local un proxy devrait également fonctionner sans préciser le -L, mais tu crées de la charge machine inutile que -L est précisément là pour éviter... sauf bien sûr si tu as une autre bonne raison de "proxyfier" les flux de fichiers stockés sur le cloud !

Limitation pour l'usage que tu envisages :
La plupart des applications qu'on utilise ont besoin de savoir le nom et taille des fichiers (et parfois la date/heure).
Pour le nom, il n'y a pas de problème, astreamfs présentera toujours un nom qui sera file00001 si on ne lui a rien indiqué, mais peut aussi être basé sur l'URL passée (-J), sur les mêmes algorithmes que curl (-JO), ou carrément spécifié (--output nom_fichier).
Pour la taille par contre, si elle n'est pas spécifiée, astreamfs va chercher à récupérer cela au démarrage, car, comme expliqué en préambule, ça planterait sans doute pas mal de programmes d'afficher une taille bidon (genre 4096 octets) et de la changer quand on lit réellement le fichier.
Or pour récupérer la taille, la seule possibilité standard en HTTP c'est d'accéder à la ressource. En l'occurrence astreamfs va faire un "range" pour demander le premier octet, ce qui révèle la taille.
Donc si tu ne spécifies pas les tailles de tes fichiers, le démarrage :
- va être long car astreamfs va (en série) accéder à chacun des fichiers dans le montage pour trouver leur taille.
- pour 1fichier.com, ton serveur intermédiaire va donc "consommer" des jetons de download qui sont en nombre limité par utilisateur (limitation du serveur API 1fichier.com à environ 500 jetons).

Bien sûr, si le nombre de liens que tu as vers des fichiers stockés sur 1fichier.com est par exemple une douzaine, ça n'a pas vraiment grande importance.

Si par contre tu en héberges une centaine, ça va devenir pénible au lancement... et si c'est plus de 500, ça ne marchera tout simplement pas car à un moment 1fichier.com va refuser de te donner de nouveaux "jetons" tant que d'anciens jetons ne sont pas échus (ce qui peut prendre jusqu'à 50 minutes).

Pour contourner cela, dans la "préparation", si cela fait du sens pour ton cas d'usage (fichiers qui changent peu souvent), l'idéal est de préciser à astreamfs la taille de chacun des fichiers, ainsi il n'a plus à faire la lecture de chaque fichier et tu n'as plus les inconvénients ci-dessus au lancement de astreamfs.

Pour date/heure c'est moins grave. Si elle n'est pas spécifiée, c'est celle du répertoire de montage qui est utilisée, et la date/heure est ensuite changée si le fichier est accédé réellement. Ce changement de date pose en général moins de problème aux applications (sauf cas particuliers comme rsync par exemple qui se sert des dates pour déterminer si un fichier doit être sauvegardé ou pas !). Si les tailles de fichiers ne sont pas précisées (cf ci-dessus), lorsque astreamfs fait l'accès au range "0-0" pour récupérer la taille, il récupère aussi au passage la date/heure du serveur (quand cette information est renvoyée par le serveur).

L'exemple est donné dans mon script 1fichier qui lit en web scraping les pages du site 1fichier.com et crée à partir de ça une arborescence identique pour astreamfs.
Parce que oui, c'est peut-être "gadget", mais tu peux créer des sous répertoires virtuels dans le montage.

Les options sont -S pour préciser la taille, -T le timestamp (timestamp Linux), et -P le chemin virtuel.

Dernière modification par Zakhar (Le 27/11/2021, à 20:30)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

flanfrit

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

Merci pour ces infos.
Effectivement nous parlons de plusieurs milliers de fichiers.
Même si la majorité des fichiers sont sur Uptobox (une limitation de jetons existe aussi sur Uptobox?), je pense qu'il faudrait donc passer la taille et le timestamp de chaque fichier à astreamfs.
Pourrais-tu me dire si mon idée est faisable:
- Je fais en sorte de stocker dans une base de données les informations des fichiers (nom, taille, timestamp, hébergeur et id). Cela me permettra de mettre à jour les informations du fichier dans la base de données si nécessaire.
- Je créé un endpoint sur mon appli qui me retourne une chaine de caractères avec l'ensemble de la commande astreamfs à exécuter pour monter l'ensemble des fichiers. Je pourrais donc exécuter cette commande avec un curl sur mon endpoint. Cette commande sera buildée sur base des infos que j'aurai dans ma DB. Saurais-tu me dire si il y'aurait une limitation avec le nombre de caractères de cette commande (plusieurs milliers de fichiers avec le -R et le -T pour chaque...) ?

Une autre question: Pour les séries j'aimerai faire un sous répertoire avec le nom de la série et la saison. Si j'ai bien compris, cela peut être fait avec l'argument -P c'est bien cela?
Si je met par exemple un -P /ma_serie/saison1 sur chaque fichier de la saison, j'aurai bien tous les fichiers des épisodes dans /mnt/test/ma_serie/saison1 ?

Zakhar

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

Oui, bravo c'est exactement ça.

C'est ce que faisait le script 1fichier : construction de la ligne de commande et lancement de celle-ci (par "eval" puisqu'on parle d'un script).

Si tu as plusieurs milliers de fichiers, il est indispensable de faire cette "préparation".

Oui les répertoires peuvent être simulés ainsi :

$ astreamfs -P '/ma_serie/' -P '/ma_serie/saison1/' https://1fichier.com/?12345 --output=Ma_Serie_S01E01.mkv -T 112345 -S 12345678  https://1fichier.com/?12346 --output=Ma_Serie_S01E02.mkv -T 112345 -S 1234567 -P '/ma_serie/saison2/' https://1fichier.com/?123456 --output=Ma_Serie_S02E01.mkv -T 112345 -S 12345678 /tmp/test

$ tree -a /tmp/test
/tmp/test
└── ma_serie
    ├── saison1
    │   ├── Ma_Serie_S01E01.mkv
    │   └── Ma_Serie_S01E02.mkv
    └── saison2
        └── Ma_Serie_S02E01.mkv

3 directories, 3 files

$ ll /tmp/test/ma_serie/*
/tmp/test/ma_serie/saison1:
total 13262
dr-xr-xr-x 2 zakhar zakhar       40 nov.  27 20:28 ./
dr-xr-xr-x 2 zakhar zakhar       40 nov.  27 20:28 ../
-r-xr-xr-x 1 zakhar zakhar 12345678 janv.  2  1970 Ma_Serie_S01E01.mkv*
-r-xr-xr-x 1 zakhar zakhar  1234567 janv.  2  1970 Ma_Serie_S01E02.mkv*

/tmp/test/ma_serie/saison2:
total 12056
dr-xr-xr-x 2 zakhar zakhar       40 nov.  27 20:28 ./
dr-xr-xr-x 2 zakhar zakhar       40 nov.  27 20:28 ../
-r-xr-xr-x 1 zakhar zakhar 12345678 janv.  2  1970 Ma_Serie_S02E01.mkv*

Attention, tu ne peux pas spécifier direct /ma_serie/saison1/, il faut d'abord spécifier son répertoire père /ma_serie/, sinon celui-ci n'existe pas et ça bugge (sans doute une amélioration à apporter !).
Par contre pour /ma_serie/saison2/, on n'a pas besoin de re-créer le parent /ma_serie/ qui existe déjà.

Attention aux pièges de espaces et caractères spéciaux pour les lignes de commande !

Comme tu le vois, ça marche ici. Même si les liens sont totalement bidons, l’arborescence peut s'afficher puisqu'on a donné la taille (le nom, le path et la date/heure) de chaque fichier. Il n'est donc pas besoin d'accéder au serveur pour afficher l'arborescence. Bien sûr, avec les liens "bidons" ci-dessus, si j'essayais ensuite d'ouvrir/cliquer sur un des fichiers ça ne marcherait pas, c'était juste pour l'exemple !

astreamfs a des options "globales" qui s'appliquent indépendamment des fichiers spécifiés, comme par exemple le nom du filesystem.
Mais la majorité des options s'appliquent à chaque URL.
Le principe est de construire une liste d'option et l'appliquer à l'URL "en cours".
Quand on passe à l'URL suivante, on hérite des options de l'URL précédente, et les paramètres spécifiés à la suite vienne "écraser" ces valeurs par défaut.
Le plus simple pour ne pas s’emmêler les pinceaux est de toujours spécifier la taille (-S) la date facultativement (-T) et le nom (--output) après l'URL.
Pour les "Path", au contraire, ils ne s'appliquent qu'à partir des URL suivantes.

Fais des tests sur un petit nombre de fichiers et n'hésite pas à regarder l'aide (--help) et poser des questions.

La limitation de la ligne de commande dépend de ton shell.
On obtient la taille ainsi :

getconf ARG_MAX
2097152

Donc tu vois, sur Ubuntu, bash supporte une ligne de commande est au dessus de 2Mo... de quoi mettre plusieurs milliers de fichiers.

Par contre si tu étais sur cygwin (l'ancienne méthode pour faire du GNU sur W$) la limitation est ridicule du genre 32k... mais bon, tu n'es sans doute pas dans ce cas puisque astreamfs n'est pas prévu pour W$... encore qu'il n'y a pas de raison qu'il ne fonctionne pas sous WSL/WSL2 !..

Si ça "débordais"... j'ai dans le /todo de pouvoir utiliser un fichier de paramètres au lieu de mettre en ligne de commande... mais je suis sur un autre développement pour améliorer le "moteur de lecture" en ce moment.

Pour ta base de données, si tu veux simuler les répertoires aussi, il faut que tu gères ça également.

Pour les limitations de l'API uptobox... je n'en sais rien car je ne suis pas client premium chez eux : ils refusent qu'on fasse du stockage "Cold", or 1fichierfs me sert également pour mes propres sauvegardes lesquelles sont évidemment chiffrées et partagées avec absolument personne... ce qui pourrait me faire "bannir" de uptobox.

Dernière modification par Zakhar (Le 06/12/2021, à 10:52)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

Zakhar

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

Voila, le nouveau moteur générique de stream fonctionne très bien en lecture.

Au programme :

• Meilleure gestion des requêtes de lecture séquentielle qui arrivent dans le désordre (performance améliorée car moins de "sous-requêtes" dans ce cas)

• Jusqu'à 32 streams en parallèle (4 précédemment)

• Appel fuse read_buf() par défaut, plus performant (splice si possible).

• Statistiques plus détaillées

• Code moins complexe (pas de locks), plus générique et évolutif.

• Meilleur mode "debug" qui trace systématiquement toutes les fonctions.

• Possibilité de générer un exécutable sans statistiques: plus compact et rapide (indétectable sur une machine "normale"!).

Comme il n'y a pas d'urgence, la dernière release (1.8.4) datant de mars 2021 et marchant fort bien (quelque "race condition" connues mais visiblement pas dramatique), je vais continuer à faire évoluer le "moteur" pour y fusionner la partie écriture.
En attendant ça tourne bien sur mes machines.

Avec l'ancien moteur de lecture, la performance de "stream" s'effondre totalement au delà de 4 lectures séquentielles (streams) en parallèle. Donc sauf si quelqu'un est gêné par cette limitation actuelle et préfère la nouvelle mouture à 32... je vais attendre de finaliser avant de vous faire ce qui sera sans doute une 2.0.0

Du côté de 1fichier.com, pas de nouvelles hélas de la fonction "upload amélioré pour Premium", la team 1fichier a d'autres soucis que vous avez peut-être constatés si vous avez voulu renouveler votre abonnement !

Dernière modification par Zakhar (Le 16/01/2022, à 19:58)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

sefaaras

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

Pourquoi est-ce que j'obtiens une telle erreur ?

[1fichierfs  1321.817] ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/download/get_token.cgi` name=`https://1fichier.com/?...`.
[1fichierfs  1321.817] INFO: >>> API(out) (iReq:259) retry=0 json size=45 http_code=403
[1fichierfs  1321.817] ERROR: http_code 403 on get_token json resp.:`{"message":"Excess slots #915","status":"KO"}` for https://1fichier.com/?...
[1fichierfs  1321.821] ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/download/get_token.cgi` name=`https://1fichier.com/?...`.
[1fichierfs  1321.821] INFO: >>> API(out) (iReq:260) retry=0 json size=45 http_code=403
[1fichierfs  1321.821] ERROR: http_code 403 on get_token json resp.:`{"status":"KO","message":"Excess slots #915"}` for https://1fichier.com/?...
[1fichierfs  1321.821] ERROR: Ignoring: (http_code: 403) url=`https://api.1fichier.com/v1/download/get_token.cgi` name=`https://1fichier.com/?...`.
[1fichierfs  1321.821] INFO: >>> API(out) (iReq:258) retry=0 json size=45 http_code=403
[1fichierfs  1321.821] ERROR: http_code 403 on get_token json resp.:`{"message":"Excess slots #915","status":"KO"}` for https://1fichier.com/?...

Aussi, pouvez-vous nous contacter pour un problème important ?

Zakhar

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

Bonjour Sefaaras,

"Excess slots #915"

C'est parce que vous accédez à trop de fichiers dans un temps court sans avoir activé l'identification réseau.

J'avais eu un long échange à ce sujet avec la team 1fichier et ça ne changera pas car c'est fait pour limiter les abus. On a droit environ à 500 "slots" sachant qu'un "slot" est conservé entre 30 et 50 minutes.

L'identification réseau, lorsqu'elle est possible, contourne le "problème" au prix d'une performance un peu réduite à l'ouverture de fichiers.

Vous pouvez par exemple déclarer votre IPV4 (publique) dans l'identification réseau, et forcer 1fichierfs en ipv4 via l'option -4, ainsi lorsque les "slots" sont épuisés, 1fichierfs tentera d'utiliser à la place "l'identification réseau".

Et à votre écoute pour le "problème important" !..

P.S.: pour confirmer vous pouvez activer les statistiques par l'option

--stat-file=.stats

, lorsque l'erreur se produit, vous affichez les statistiques :

cat 1fichier/.stats

et là vous devriez voir une très longue liste (~500) de fichiers actifs. Selon la longueur des noms de fichiers, il est même possible que la liste soit coupée car la longueur des statistiques est limitée à 128ko

Dernière modification par Zakhar (Le 28/01/2022, à 08:32)

---

"A computer is like air conditioning: it becomes useless when you open windows." (Linus Torvald)

sefaaras

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

Il plante immédiatement lorsque je redémarre. Pas tous, juste certains. Il y a un truc qui s'appelle gauche, ça commence à 30. Qu'est-ce que ça veut dire? Un lien ouvert ne se ferme pas immédiatement ?

Uptime: 00:02:45

Readers:
     Down. N.Req  Avg Time  Max Time   Ref  Qu N.Err Speed Av.Sp
[01] 1504K   104    0.0606    0.5471  idle   0     2     0  100K
[02] 1340K   100    0.0626    0.5649  idle   0     4     0 85760
[03] 1408K    99    0.0608    0.3587 (  11)  0     0     0 90112
[04] 1564K   106    0.0534    0.2094 (  11)  0     0     0  104K
solo 3124K   226    0.0876    0.9542               0        157K
----------------------------------------------------------------
Tot. 8940K   635    0.0693    0.9542         0     6     0  525K

API:
                        N.Req  Avg Time  Max Time Retry N.Err
folder/ls.cgi         :     3    0.1045    0.1319     0     0
download/get_token.cgi:    13    0.0608    0.2373     0     3
fallback/get_token    :     1    0.2215    0.2215     0     1
--------------------------------------------------------------
Total                 :    17    0.0779    0.2373     0     4

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

             Number Memory
Allocations:  27211  30.4M
Frees      :  27048  29.9M
Difference :    163   587K
Contentions:     11      1

Live streams: |Write| 0    (Read) 13
  Ref   Size  Left Lnk Er N.Loc N.Stm Path
(   1)  xxxG 00:00   0  E     0     1 /...
(   2)  xxxG 28:58   0        1    15 /...
(   3)  xxxG 28:58   0        1     2 /...
(   4)  xxxG 29:16   0        1   118 /...
(   5)  xxxG 27:25   0        1    92 /...
(   6)  xxxG 27:16   0        1     2 /...
(   7)  xxxG 28:11   0        1     9 /...
(   8)  xxxG 27:52   0        1     2 /...
(   9)  xxxG 28:49   0        1    97 /...
(  10)  xxxG 00:00   0  E     0     1 /...
(  11)  xxxG 29:27   2        1   107 /...
(  12)  xxxG 00:00   0  E     0     1 /...
(  13)  xxxG 29:16   0        1     9 /...