je pense pouvoir allouer 32go de ram pour la VMs qui abritera mon client bittorrent
Ce qui lui fait par défaut 16Go de RAM-disk, mais si elle ne fait tourner qu'un client torrent, vous pouvez sans doute facilement monter à 30Go
hum, par certain qu'il y aura qu'un seul client torrent, si je peux partager avec mes frères, ça serait top.
Oui chacun son iso d'ubuntu téléchargée en Torrent. 😛
Enfin à 30Go on stocke une 20 d'images Linux !
ok, ça devrait donc aller.
(10 Juin 2019) Version 1.4.1

Nouveautés par rapport à la 1.4.0
  • Crash : dans la lecture des statistiques sous certaines conditions (je me demande comment ce bout de code écrit avec les pieds pouvait bien fonctionner ! 😛 ).
Mise à jour recommandée si vous comptez afficher les statistiques.
Zakhar a écrit(10 Juin 2019) Version 1.4.1

Nouveautés par rapport à la 1.4.0
  • Crash : dans la lecture des statistiques sous certaines conditions (je me demande comment ce bout de code écrit avec les pieds pouvait bien fonctionner ! 😛 ).
Mise à jour recommandée si vous comptez afficher les statistiques.

mdrrrr, pour des simples mortels comme nous, c'est passé inaperçu lol. Merci à toi.
Je devais penser à autre chose en écrivant ce bout de code... et par "malchance", dans la plupart des cas il marchait ! :lol: 😃
Donc je ne me suis pas aperçu de la bourde tout de suite.
ANNONCE :

Voir post #1.

Le driver bute actuellement sur des limites imposées par le serveur sur les petits fichiers. La team 1fichier ne souhaite pas changer ce comportement du serveur par crainte d'attaque.

Pour éviter que des actions que vous fassiez innocemment, comme archiver un répertoire contenant 1000 photos (2 clics de souris) vous fasse passer pour des attaquants, et pour préserver le service tel qu'il est et qui nous plaît bien, je suspens le développement en l'état.

Bien sûr les bugs potentiels continueront à être corrigés.

Désolé pour ceux qui attendaient l'écriture, je ne vais pas l'implémenter, mais me consacrer maintenant plutôt au driver http(s) générique (astreamfs) qui a pris du retard.
Aucun soucis, ce que tu as fait est Terrible !!! Mon plex tourne bien bien mieux que Rclone avec GoogleDrive. Dynamique, Rapide, fluide que du bonheur. Merci à toi.
Pour L'écriture, j'utilise leur FTP. Ça évite des demandes d'api supplémentaires. J'ai pas trop compris avec plex comment le nombre de demandes se faisait. Scan, click de lecture. marche arrière ou avant. En tout cas ça plante pas et cela grâce toi. Donc, merci 🙂
Oui, le ftp fonctionne bien, c'est juste que ça fait des "manipulations".

Mais bon, comme il est désormais démontré par A + B que 1fichier n'est pas adapté pour des sauvegardes de petits fichiers nombreux mais au contraire peu de gros fichiers, du coup le nombre de manipulations en ftp est nécessairement faible et tolérable, puisque tu l'utilises sans doute pour peu de gros fichiers !
jaxx21 a écritJ'ai pas trop compris avec plex comment le nombre de demandes se faisait. Scan, click de lecture. marche arrière ou avant. En tout cas ça plante pas et cela grâce toi. Donc, merci 🙂
Contrairement à la team 1fichier qui a l'air de penser que les secrets sont la meilleure sécurité... si tu veux comprendre comment ça marche, tout le code est en ligne ici : https://gitlab.com/BylonAkila/astreamfs. Bon courage. 😃
Meilleure explication des limitations dans le post #1

Bien sûr, ce forum est ouvert. La team 1fichier est bienvenue à s'exprimer sur cela si elle le souhaite.
7 jours plus tard
Salut, donc, je ne sais pas si tu continueras à modifier un peu ton api mais je te colle un debug apres une réinstallation de mon vps.
Je fait comme d'hab pour l'install mais au lancement de ma commande pour monter l'api, j'ai cette erreur:
[1fichierfs     0.000] NOTICE: started: Tuesday 25 June 2019 at 00:31:44
[1fichierfs     0.003] NOTICE: successfuly parsed arguments.
[1fichierfs     0.003] INFO: log level is 7.
[1fichierfs     0.003] INFO: user_agent=1fichierfs/1.4.1
[1fichierfs     0.003] INFO: adding options=-orw,fsname=1fichier.com,subtype=1fichierfs
[1fichierfs     0.003] DEBUG: init_dir: `/` (id=0)
[1fichierfs     0.003] DEBUG: lock 999
[1fichierfs     0.003] INFO: <<< API(in) (iReq:1) folder/ls.cgi POST={"folder_id":0,"files":1} name=/
[1fichierfs     0.107] INFO: >>> API(out) (iReq:1) retry=0 json size=4825
[1fichierfs     0.107] ERROR: could not find create_date for dir: Root
je précise, que 1fichier a mis en place (ou je viens de la découvrir) un system pour partager des comptes entre compte.
En gros, un ami a mis mon mail d'inscription 1fichier dans son compte. Du coup, je me retrouve avec son compte dans mon compte ou je peux tout faire (supprimer...)

img

Donc, l'erreur vient peut être de la. J'attends qu'il vire son compte du mien car je ne peux pas le faire (ce qui est pas terrible du coup) et relancer l'api.
Peut être qu'il y a besoin de l'api de la personne avec moi.On se retrouverai avec une double connection lol.
Dès qu'il vire son compte je redonne des news.
Merci

EDIT: Donc, oui, il a enlevé son compte du miens et cela fonctionne impec.Donc je vais rester comme ca. Merci encore 🙂
C'est sans doute dû à cela, mais pour reproduire le bug et le corriger, il faudrait que j'arrive à créer la situation sur mon compte.
Comme c'est un bug au démarrage, c'est très facile à debugger.

Mais je ne comprends pas très bien la chose... j'avais déjà partagé des données avec un collègues, et corrigé un bug à ce propos. Mais là c'était un répertoire que j'avais créé moi-même et que je lui avais ensuite partagé en mettant son mail. Le collègue en question est également "premium" 1fichier.

Comment on recrée le cas que tu cites ?
S'agit-il du programme d'affiliation ?
L'ami en question qui met ton e-mail doit avoir un compte premium ou un compte ordinaire va bien ?
... ou alors si je comprends ce que tu as écrit, il a simplement "usurpé" ton e-mail ?... 😛
C'est bizarre que 1fichier autorise plusieurs comptes avec le même e-mail, je pensais que cet identifiant était la clé.
Si c'est un compte ordinaire, je peux facilement créer un compte bidon de test pour reproduire la chose.
Très certainement que l'entrée ainsi créée se présente comme un répertoire qui n'a pas de date de création, ce qui ne plaît pas à mon driver.
Dans ce cas, il faudrait voir comment on reconnaît ces entrées avec un autre attribut, pour ne pas chercher à lire une date de création qui n'existe pas !


Sinon, oui, bien sûr, je continue à corriger.
Là je suis reparti sur le driver générique où je back-porte les améliorations où 1fichierfs était en avance. Ensuite le driver générique prendra de l'avance, et le "back-port" se fera à l'envers (vers 1fichierfs) .... de temps en temps.
Alors, c'est dans son compte qu'il y a partager. au lieu de partager un dossier, il partage la racine de son compte. Et il rentre le mail que je lui ai dit (de mon compte).
Et quand c'est la racine, et bien ca s'incruste dans ton compte et impossible de l'enlever. Du moins, j'ai pas vu l'option.Et dedans, je peux supprimer, lire...
Il a un premium et je ne sais pas pas si c'est dispo pour les non premium.
Ok, en l'occurrence j'ai partagé un dossier avec un collègue (pas la racine !) en lui donnant les droits écriture/suppression dans le dossier, c'est celui qui donne le partage qui définit si c'est lecture seule ou pas.

Mais je n'ai jamais reçu de partage, donc je ne sais pas comment ça se manifeste. Pas sûr que le fait de partager la racine ou autre chose change quoi que ce soit dans ce que voit celui qui reçoit le partage.

Je vais voir si avec un compte non-premium on peut partager, et si ce n'est pas le cas, je t'enverrai mon e-mail 1fichier en MP pour que tu me partages un répertoire que tu auras créé à cet effet avec 2 ou 3 fichiers bidons dedans pour le test.
Ok, vu.
C'est possible de créer un partage même avec un compte gratuit.
Il y a un peu de travail pour le faire "proprement" selon que celui qui a partagé a autorisé ou pas l'écriture, et aussi s'il a "masqué les liens".

Aussi, il faut à l'idéal gérer les "collision de nom" par exemple si on un répertoire /Vidéos à la racine et que quelqu'un nous partage un répertoire /Vidéos.
Ou tout simplement 2 partages de racines vont tous deux s'appeler "Root".

Le nom visible du répertoire sera donc : "Nom_email"

En attendant que j'aie eu le temps de faire les modifications, le contournement est effectivement de ne pas faire ce genre de partages... désolé !..

Si vraiment tu as besoin de recevoir des partages, je peux faire un patch vite fait, il suffit de considérer l'absence de date comme un simple warning... mais ça ne traitera pas tout le reste ci-dessus.
Non non, pas de soucis.prends ton temps. c'est pas urgent. merci quand même.
18 jours plus tard
Les partages sont très mal testés par la team 1fichier.

Visiblement on ne parvient pas à récupérer les liens quand l'utilisateur a spécifié "hidden_links". J'ai signalé, ils sont dessus.

Il y avait aussi une inconsistance, les "id" des répertoires sont normalement numériques, or le retour pour les partages était en chaîne de caractères. Signalé, et corrigé par 1fichier.

On va attendre les corrections côté serveur pour faire un truc qui marche à peu près !..

[Edit] corrections serveur effectuées. Par contre traiter les partages va assez loin, puisque même le listage du répertoire est différent en cas de partage de la racine !
Voila, à ma demande la team 1fichier a rajouté la "create_date" qui n'était pas dans le retour JSON pour les partages.

Donc avec cela, le driver fonctionne "out-of-the-box" pour les partages avec les restrictions suivantes... en attendant que j'aie fait le code qui va bien pour y remédier :

- Le partage ne peut pas être la racine du compte : ça ne plantera pas, mais les fichiers listés seront ceux de celui qui reçoit le partage, et pas ceux de celui qui a partagé.
- Il faut donc nécessairement que ce soit un "sous-répertoire" qui soit partagé. Ce sous-répertoire ne doit pas avoir le même nom qu'un répertoire déjà existant sur le compte de celui qui reçoit le partage. Ca ne plantera pas, mais dans ce cas le système (Linux) ne verra qu'un seul des deux répertoires puisque le nom est la clé d'accès. Aussi, dans tous les cas les fichiers listés sont ceux de celui qui reçoit le partage. Cependant, cela peut facilement se corriger en changeant le nom de ses propres répertoires.
- Le répertoire ne doit pas être partagé avec "liens masqués"... sinon la lecture des fichiers sera impossible ! (ce n'est simplement pas encore implémenté). Il est même possible que ça plante simplement vu que le driver s'attend à trouver des URL qui ne sont pas présentes dans ce cas.
- Si le répertoire est partagé en "lecture seule", le récepteur du partage pourra tenter des renommage/suppression, le driver ne les empêchera pas. Cependant, comme le partage est en lecture seule, le serveur va refuser l'opération, et l'utilisateur aura alors une erreur (pas un plantage !)


@jaxx21 : voila, donc si tu veux tester les partages avec tes amis, en gros, à condition qu'ils ne partagent pas la racine, ce sera opérationnel avec le driver en l'état... et bien sûr qu'ils n'utilisent pas "liens masqués", sinon le résultat sera "non prévisible" car le driver s'attend à trouver des URL qu'il ne verra pas !


P.S. : j'avais retiré la "log" vu que ça marchait sans plantage jusqu'alors, je vais la remettre car ce matin j'ai constaté un plantage... est-ce dû aux modifications récentes pour les partages... qui sait !