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

Zakhar · Le 16/06/2019, à 15:14

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 écrit :

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

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.

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

Zakhar · Le 18/06/2019, à 07:29

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.

jaxx21 · Le 25/06/2019, à 08:44

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...)

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

Dernière modification par jaxx21 (Le 25/06/2019, à 09:11)

Zakhar · Le 25/06/2019, à 17:36

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.

Dernière modification par Zakhar (Le 25/06/2019, à 17:45)

jaxx21 · Le 28/06/2019, à 08:27

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.

Dernière modification par jaxx21 (Le 28/06/2019, à 13:43)

Zakhar · Le 28/06/2019, à 17:16

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.

Dernière modification par Zakhar (Le 28/06/2019, à 17:19)

Zakhar · Le 30/06/2019, à 09:36

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.

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

jaxx21 · Le 01/07/2019, à 19:36

Non non, pas de soucis.prends ton temps. c'est pas urgent. merci quand même.

Zakhar · Le 19/07/2019, à 09:28

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 !

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

Zakhar · Le 21/07/2019, à 07:47

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 !

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

jaxx21 · Le 22/07/2019, à 20:18

haaa ouais, quand même !!! celui qui ne sait pas tout ca il est mort quoi lol. Merci, Je préfère attendre un peu. Je trouve dommage que 1fichier donne pas la possibilité à celui qui reçoit d'annuler ce partage. Merci pour tes efforts infinis.

Dernière modification par jaxx21 (Le 22/07/2019, à 20:18)

Zakhar · Le 22/07/2019, à 21:39

Oui, ce serait effectivement mieux !

En plus la fonctionnalité "liens masqués" c'est vraiment de la corde raide. L'obtention du ticket de téléchargement repose alors que le nom du fichier... et quid si le "partageur" change les noms ou emplacements des fichiers. Bref, c'est limite...

Bon, maintenant que le côté serveur est corrigé, je pourrai à l'occasion faire le code qui manque pour tâcher de gérer ça du mieux qu'on peut avec les limites inhérentes de la chose.

Zakhar · Le 28/07/2019, à 23:18

Le code est fait, ce sera la 1.5.0.

La période de test commence.

Ça gère, comme annoncé, aussi bien les partages read-only, accès complet ou liens cachés, que ce soit la racine ou un sous-répertoire.

Il y a une faiblesse inhérente dans la fonctionnalité "lien cachés", c'est que le propriétaire du fichier (celui qui partage) peut duper celui qui reçoit le partage en changeant le nom du fichier au "mauvais moment". La protection contre cela obligerait à faire des pieds au mur en vérifiant la "hash" à chaque nouveau jeton de téléchargement et je n'ai pas envie d'aller aussi loin !
Cela se produit parce que en "lien cachés", la clé d'accès n'est plus l'URL du fichier (puisque précisément on ne l'a pas !) mais le nom de celui-ci. Or l'URL ne peut pas être changée... mais le nom du fichier si !..
Donc la protection "raisonnable" si on reçoit un partage en "liens cachés" et d'activer les statistiques, et de vérifier que les fichiers partagés que l'on récupère sont copiés en une seule fois (case "Loc" vaut 1).

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

jaxx21 · Le 29/07/2019, à 20:31

Salut, ca devient compliqué dans le code. Le truc de fou. Merci pour la mise à jour.

Zakhar · Le 29/07/2019, à 23:04

jaxx21 a écrit :

Salut, ca devient compliqué dans le code. Le truc de fou. Merci pour la mise à jour.

Y compris côté serveur !
Peu de gens doivent avoir testé les API avec les partages, j'ai une erreur HTTP 500 retournée par le serveur lorsque je supprime un répertoire dans un partage avec droit d'écriture.
On n'est pas au bout des surprises sur les partages.

[Edit] "bug" corrigé par la team 1fichier. En réalité cette fonction n'est pas disponible sur l'interface web. Quand on reçoit un partage avec droit d'écriture, on peut donc y créer des répertoires... mais on ne peut pas en supprimer, que le répertoire soit déjà existant, ou qu'on vienne de le créer !.. Via l'API, on peut désormais faire cela.

Dernière modification par Zakhar (Le 02/08/2019, à 08:25)

Zakhar · Le 06/08/2019, à 17:56

(6 Août 2019) Version 1.5.0

Nouveautés par rapport à la 1.4.1

Fonctionnalités : gestion des partages reçus, que ce soit la racine ou un sous-répertoire, y compris les modes "lecture seule" et "liens cachés" (voir avertissement).
Documentation : explication de la limitation globale liée à la politique de 1fichier, en plus de l'indication que le driver gère les partages.

Avertissement !
Attention aux partages avec "liens cachés" !.. Ce genre de partage pourrait être à l'origine d'attaque de la part de celui qui vous a partagé les fichiers.
En effet, comme on n'a plus les liens (ils sont cachés !) la clé d'accès au fichier devient le nom du fichier. Or celui qui vous a partagé le répertoire peut très bien changer les noms de fichier "au bon moment". Ce qu'il pourrait alors arriver est la chose suivante : vous avez commencé à visionner le film de Tonton Jacques en vacance dans un partage reçu, le driver a récupéré un lien de téléchargement et vous a "streamé" le film. Au bout de 30 minutes vous mettez en pause parce que vous recevez un coup de fil. Une fois le coup de fil terminé, vous reprenez le visionnage. A ce moment là, le lien de téléchargement initial est échu et le driver en demandera un nouveau à partir du nom du fichier. Oui mais voila, celui qui vous a partagé le film de vacances de Tonton Jacques, vient de remplacer ce film là par autre chose qui choquerait la vue de vos enfants. Le driver va alors récupérer le lien sur cet "autre chose" et continuer le visionnage à l'adresse où il en était. Il est possible que votre visionneur (VLC, Kodi) shkreugnognote un peu parce qu'il va manquer des trames vidéos, mais la lecture pourrait fort bien se poursuivre sur tout autre chose que le film attendu.
Bien sûr la même "arnaque" peut se produire pour un exécutable (plus difficilement parce qu'on ne le "streame" pas !) avec l'effet d'exécution de code arbitraire.

La défense contre cela :
- essayez d'expliquer à vos amis qui vous partagent des fichiers de ne PAS utiliser cette fonctionnalité "liens cachés".
- si malgré tout vos amis ne comprennent pas (ou font semblant pour vous arnaquer !), la protection actuelle consiste à utiliser les statistiques et plutôt récupérer les fichiers en local en une seule fois. Vous pouvez alors vérifier avec les statistiques que pour chaque fichier dans le partage, la valeur de "N. Loc" (représentant le nombre de tickets obtenus) et bien de 1 par fichier, et pas 2 ou plus !.. Ainsi vous êtes assurés de ne pas avoir eu de changement de fichier en cours de téléchargement.
- la protection contre la substitution de fichier en cours de téléchargement serait possible en relisant le "hash" (whirlpool) du fichier, mais cela ralentirait considérablement pour ces fichiers là, et c'est hors de proportion pour une fonctionnalité qui est un peu "bidon".

Une telle chose ne peut pas se produire avec un partage "normal" (lecture seule ou accès complet) car la clé d'accès reste le lien sur lequel l'utilisateur n'a pas la main. Changer le nom d'un fichier ne change pas son lien !.. La seule chose qui pourrait alors arriver est une suppression du fichier partagé en cours de streaming. Mais il n'y a pas de risque de "corruption" volontaire ou pas, juste un risque que l'opération demandée échoue !

Faut-il faire la mise à jour : si vous ne recevez pas de partage de la part de vos amis, la mise à jour n'est pas nécessaire. La version précédente sait tout à fait gérer les partages que vous faites vous-mêmes vers vos amis. Par contre si vous comptez recevoir des partages, la mise à jour est plus que recommandée sinon il y aura des limitations importantes (voir post plus haut) au type de partage que vous pouvez recevoir.

Détails d'implémentation :
- le partage reçu va apparaître sous le nom "nom_du_répertoire" + " on " + "e-mail_de_celui_qui_partage". C'est à dire la même chose que l'on voit sur l'interface 1fichier si on met celui-ci en anglais.
- lorsque c'est la racine qui est partagée, le nom du répertoire transmis par 1fichier est "Root". On a donc "Root on e-mail"
- il existe une différence par rapport à l'interface web si un utilisateur vous fait plusieurs partages imbriqués. Dans ce cas on voit à la racine l'ensemble des partages, comme sur l'interface web, mais quand on déplie l'arborescence, chaque partage garde les droits du répertoire du partage à la racine de votre compte, et on ne voit pas que les sous répertoires sont aussi partagés avec d'autres droits. Ce genre de partage est de toute façon un peu "piégeux" et sans doute un cas d'école !
- meilleur fonctionnement que le site web... sur un "bug" que j'ai signalé à 1fichier, corrigé pour l'API, pas pour le site web. Il s'agit de la suppression de répertoires dans les partages avec accès complet. Vous pourrez le faire avec le driver... pas avec l'interface web. C'est un peu idiot d'avoir accès "total" et de pouvoir créer des répertoires qu'on ne peut ensuite pas supprimer... mais bon ça fonctionne bien via l'API maintenant que le team 1fichier a corrigé.
- le driver filtre les opérations impossibles selon les droits du partage. "Accès complet" permet de tout faire. "Lecture seule" interdit les suppressions, renommages, et copies (lien dur) vers le partage. "Lien cachés" interdit en plus les copies (liens dur) en provenance du partage. Le code retour est "accès refusé". La journalisation détaillée indique que l'opération était impossible. Le statut "lecture seule" est visible sur les droits du répertoire qui sont mis en lecture seule. Ainsi si vous utilisez "default_permissions", c'est le kernel qui filtrera, vous aurez toujours bien accès refusé, mais rien dans le journal puisque le driver ne sera pas appelé, le kernel ayant filtré avant !
- si vous avez activé le plus haut niveau de journalisation (7), le listage fera apparaître un indicateur W, R ou H pour les répertoires partagés selon leurs droits. W (write) pour accès complet, R (read-only) pour lecture seule, et H (hidden) pour liens cachés.
- non testé : les partages "transitifs". C'est à dire Alice partage à Bob, et Bob partage sa racine (qui contient le partage reçu par Alice) à Tom... Cela m'aurait obligé à ouvrir plusieurs comptes de test !.. J'espère simplement que ce cas de transitivité est réglé en ne transmettant pas les partages reçus sur la racine... En effet, Alice a partagé avec Bob, pas avec Tom... donc que Bob s'arroge le droit de partager ce qu'il a reçu d'Alice à Tom peut aller au delà du "consentement" d'Alice sur ce qu'elle souhaitait partager à qui... RGPD etc !..
- important (et intéressant !) : celui qui vous partage un répertoire n'a pas besoin d'être "premium" pour que vous puissiez utiliser ses fichiers. Un utilisateur "gratuit" vous permettra d'utiliser ses fichiers comme s'ils étaient sur votre compte... tant que celui qui reçoit le partage est abonné "premium". Donc votre fameux "Tonton Jacques" qui souhaite vous partager ses films de vacances, peut très bien prendre un compte gratuit, y déposer ses films, et vous partager le répertoire où il les a mis (ou la racine). Vous pourrez alors regarder les péripéties du Tonton en vacances avec votre compte premium via 1fichierfs, même si le film a été à la base déposé sur un compte gratuit.

Dernière modification par Zakhar (Le 06/08/2019, à 21:47)

jaxx21 · Le 13/08/2019, à 07:38

Bonjour Zakhar, on sent qu'il y a eu de l'investigation lol. Merci à toi pour cet affaire que tu as su résoudre grace à une mise à jour.

Zakhar · Le 13/08/2019, à 07:49

jaxx21 a écrit :

Bonjour Zakhar, on sent qu'il y a eu de l'investigation lol. Merci à toi pour cet affaire que tu as su résoudre grace à une mise à jour.

Oui, et deux "bugs" corrigés côté serveur !

N'hésite pas à faire un retour si ça ne fonctionne pas, ou si un autre truc est cassé. Même si je ne vais plus faire évoluer, je maintiens le programme tant que je suis client (sinon c'est difficile !) et tant que le service existe !

Zakhar · Le 14/10/2019, à 17:52

Hello, quelques news : la compilation fonctionne presque "out of the box" sur Raspberry Pi / Raspbian Buster, il faut juste rajouter -latomic dans les librairies à linker car sinon on n'a pas les "atomiques sur 8 octets".

Le driver fonctionne "à peu près correctement", mais il y a un comportement étrange de curl qui peut provoquer des "freezes" important. Le comportement bizarre est que malgré le fait que le callback retourne une erreur d'écriture, curl met "un certain temps" à rendre la main au programme. Cela ne se produit pas sur i386/amd64, je vais donc signaler la chose aux auteurs de curl !

On va bien voir la réactivité... le problème étant qu'il va sans doute falloir que j'écrive un programme spécial plus court pour prouver la chose, c'est pas gagné...

jaxx21 · Le 15/10/2019, à 07:28

Salut, Sympa comme news.Du boulot en + en tout cas pour toi. Merci et bon courage.

Zakhar · Le 15/10/2019, à 16:42

jaxx21 a écrit :

Salut, Sympa comme news.Du boulot en + en tout cas pour toi. Merci et bon courage.

Oui !

Mais contrairement à Ubuntu 16.04 où Kodi n'aime pas trop Unity, celui-ci fonctionne "out of the box" sur Raspbian, alors qu'avec VLC j'ai un bug bizarre de sous-titres qui s'affichent au milieu de la vidéo !
Un Kodi fonctionnel, qui ne nécessite qu'une souris (j'ai ça en rab !), qui prend en compte HDMI-CEC pour envoyer le son à l'écran... que du bonheur.
Reste à voir si le playback vidéo est stable, car c'était le problème sur Ubuntu, celui-ci "freezait" de temps en temps.

Donc avoir ma vidéothèque/CD-Thèque en "cloud" sur mon Kodi, c'est du tout bon pour économiser de l'électricité et de l'usure de mon PC de bureau !

Les gars de curl ont l'air réactifs sur GitHub, mais le bug n'est pas facile à "démontrer". Aussi il pourrait bien provenir de GnuTLS, ou la façon dont curl l'utilise. A suivre...

[Edit] : la communauté curl a l'air motivée et réactive... mais avec d'autres tests j'ai trouvé un contournement facile et valable sur Raspbian : utiliser OpenSSL au lieu de GnuTLS.

GnuTLS était nécessaire car je fournis (et utilise personnellement) le programme sur Ubuntu 16.04, lequel ne dispose pas de la version suffisante d'OpenSSL pour être "thread safe" dans un programme tel que celui-ci. Cependant, la version Raspbian Buster étant plus récente, la version d'OpenSSL est désormais 1.1.1d ce qui est suffisant pour le "thread safe". Il suffit donc de linker avec OpenSSL et le tour est joué : plus de bug (pour le moment !).

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

Zakhar · Le 17/10/2019, à 13:26

A l'occasion des nouveaux tests sur Raspberry, j'ai également corrigé un crash.

Le crash survenait lorsqu'une erreur se produit à la lecture d'un répertoire. On peut le reproduire facilement en coupant le réseau et en lançant le programme. Dans ce cas on va observer le crash.

Ce crash est corrigé dans ma version locale, je vais aussi faire un "backport" des améliorations mineures que j'ai fait sur le projet "père" (astreamfs) concernant l'exploration des paramètres, et je livrerait le tout prochainement dans une version 1.5.1
La version est en ce moment en observation sur mon PC et sur mon raspberry, et sera livrée dans quelque temps si tout va bien.

En attendant, si vous observez un crash dû à la lecture d'un répertoire échouée, le seul contournement est de relancer le programme !

Je vais également tâcher fournir le .deb pour Raspberry Pi Buster 32 bits. Ce sera moins "automatique" que pour Ubuntu car il n'y a pas les "ppa", je devrais donc héberger le .deb sur un de mes serveurs, et ce sera une installation par dpkg.

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

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

ca marche. MErci des onfos. bon courage.

Zakhar · Le 20/10/2019, à 22:12

(20 Octobre 2019) Version 1.5.1

Nouveautés par rapport à la 1.5.0

Crash : si le serveur renvoie une erreur lors d'un listage de répertoire, 1fichierfs crashe !.. On peut facilement le reproduire en coupant le réseau et en lançant le programme
NOUVEAU ! : première version packagée pour Raspbian (Buster) ! (voir ci-dessous)
Amélioration : meilleure gestion des paramètres.
Documentation : mise à jour, notamment pour la version Raspbian où --cacert n'est pas utile.

Nouveau !
Le programme fonctionne out-of-the box sur Raspberry Pi - Raspbian avec deux changement mineurs :
- rajouter -latomic dans les options de link (Makefile)
- linker avec OpenSSL et non pas avec GnuTLS qui présente un bug non résolu à ce jour (freeze). Donc installer la version libcurl4-openssl-dev au lieu de la version gnutls.

Si votre Raspberry Pi tourne sur Raspbian Buster (32 bits), vous avez même un package deb tout fait.
Vérifiez que vous avez la bonne version d'O.S. sur votre Raspberry:

pi@raspberrypi:/ $ uname -a
Linux raspberrypi 4.19.75-v7l+ #1270 SMP Tue Sep 24 18:51:41 BST 2019 armv7l GNU/Linux
pi@raspberrypi:/ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

Récupérez le package là : http://xslt2.0.free.fr/raspbian/1fichierfs_1.5.1~buster-1_armhf.deb (taille : 57840 octets)

Vérifiez l'intégrité du fichier

pi@raspberrypi:/ $ md5sum 1fichierfs_1.5.1~buster-1_armhf.deb
3f87f4ae7cf6197b2b5ec224207dfd8c  1fichierfs_1.5.1~buster-1_armhf.deb
pi@raspberrypi:/ $ sha256sum 1fichierfs_1.5.1~buster-1_armhf.deb
28e1c7b7b38b2920a5526a51cc9e0414fca8bec78a2ffffeb9471555ea1b8d0a  1fichierfs_1.5.1~buster-1_armhf.deb

Installez avec

sudo dpkg -i 1fichierfs_1.5.1~buster-1_armhf.deb

Enjoy!
2To de sauvegardes rattachées à votre Pi, c'est cool non.

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

jaxx21 · Le 21/10/2019, à 12:02

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

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#151 Le 16/06/2019, à 15:14

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

#152 Le 18/06/2019, à 07:29

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

#153 Le 25/06/2019, à 08:44

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

#154 Le 25/06/2019, à 17:36

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

#155 Le 28/06/2019, à 08:27

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

#156 Le 28/06/2019, à 17:16

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

#157 Le 30/06/2019, à 09:36

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

#158 Le 01/07/2019, à 19:36

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

#159 Le 19/07/2019, à 09:28

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

#160 Le 21/07/2019, à 07:47

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

#161 Le 22/07/2019, à 20:18

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

#162 Le 22/07/2019, à 21:39

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

#163 Le 28/07/2019, à 23:18

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

#164 Le 29/07/2019, à 20:31

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

#165 Le 29/07/2019, à 23:04

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

#166 Le 06/08/2019, à 17:56

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

#167 Le 13/08/2019, à 07:38

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

#168 Le 13/08/2019, à 07:49

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

#169 Le 14/10/2019, à 17:52

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

#170 Le 15/10/2019, à 07:28

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

#171 Le 15/10/2019, à 16:42

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

#172 Le 17/10/2019, à 13:26

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

#173 Le 18/10/2019, à 08:09

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

#174 Le 20/10/2019, à 22:12

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

#175 Le 21/10/2019, à 12:02

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

Pied de page des forums