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

Zakhar · Le 21/07/2024, à 23:27

Bonjour z3ndra, 1fichierfs ne fonctionne effectivement que si tu es abonné Premium car c'est une condition nécessaire pour que les APIs soient accessibles. Il n'y a pas de "solution de contournement" si tu n'es plus premium !.. De toute façon le téléchargement étant lent et bridé pour les non-premium, ça n'aurait pas trop d'intérêt.

Si tu es bien Premium, c'est qu'il y a un problème quelconque, et je ne peux t'aider qu'avec une "log" (journal).
Il faut donc faire le montage avec les options (par exemple)

--log-level 7 --log-file=/tmp/debug.txt

Si le contenu du fichier journal ne te semble pas clairement indiquer l'erreur, tu peux me donner le résultat qui se trouve dans le fichier indiqué, en l'occurrence /tmp/debug.txt dans l'exemple au dessus, plutôt en message privé (ou occulter les données "personnelles").
Si "ça ne se monte pas", le fichier journal devrait être très court. En effet, la première chose que fait le driver est d'essayer de monter la racine du compte, si ça ne fonctionne pas, il abandonne sans montage.

De mon côté, cela fonctionne parfaitement !

Dernière modification par Zakhar (Le 21/07/2024, à 23:29)

z3ndra · Le 21/07/2024, à 23:58

Merci pour ta réponse, du coup j’ai trouvé la cause du problème enfin je pense savoir lol en faite j’ai rajouté « insecure 0 0 » a la fin de mon fstab et tout est revenu entierement d’un coup . Du coup ca veut dire que c’est un souci de certificat ssl qui bloquerait le montage via l’api non ?

Zakhar · Le 22/07/2024, à 08:34

Bravo, oui, c'est bien possible.
En fait ça dépend des autorités de certifications auxquelles ta machine fait confiance par rapport au certificat utilisé par 1fichier.com
"insecure" ne va pas supprimer le chiffrement (fort heureusement !) cela va juste sauter la vérification de l'émetteur du certificat. C'est donc "insecure" au sens où si tu es victime d'une attaque "man in the middle" (quelqu'un qui s'intercalerait entre 1fichier.com et toi) tu vas gentiment l'accepter !

Si tu veux revenir en mode "secure", tu peux extraire le certificat utilisé par 1fichier.com et le forcer pour 1fichierfs.
Voici l'option :

--cacert=/home/zakhar/1fichier_ca.pem

En ayant bien sûr extrait le certificat utilité par 1fichier.com et sauvegardé sur /home/zakhar/1fichier_ca.pem

Je te laisse regarder en ligne comment on extrait un certificat !

Dernière modification par Zakhar (Le 22/07/2024, à 08:36)

b1m2n3 · Le 24/07/2024, à 23:31

Bonjour.

Tout d'abord, merci pour ce topic bien intéressant ; j'ai appris des choses, tant les explications y sont claires !

Concernant la forte contrainte apparue plutôt récemment de l'utilisation du crédit CDN lors de l'utilisation de l'API de 1fichier : y a t-il moyen d'empêcher cela ? Il a été question d'IPv6 comme solution potentielle en page précédente... Des retours à ce sujet ?
Pour ceux qui sont chez OVH par exemple, je sais que c'est possible d'office, dès les VPS premiers prix.

Aussi, je suis intéressé par une petite mise au point sur les limites de 1fichierfs en matière d'écriture ? Au tout départ du projet 1fichierfs, j'ai cru comprendre qu'il n'était question que de lecture, puis que l'écriture a aussi été intégrée par la suite, mais toujours avec "limitation sur l'écriture aléatoire (overwrite)". Hors, si je ne me trompe pas, il me semble que l'écriture aléatoire est une chose, l'overwrite (qui peut être en séquentiel ?) en est une autre. Je ne suis pas expert sur la question, mais je cherche à déterminer quelles pourraient êtres concrètement les limitations pratiques...

Exemple : dans mon cas, j'avais projeté - dans un fort idéal - y faire pointer (avec ou sans stockage local intermédiaire) un gestionnaire de téléchargement, avec si nécessaire désarchivage dans la foulée (car ce dernier point, j'ai pu lire que c'était bien possible). Dans ce scénario, il ne s'agirait à priori que de transferts séquentiels ininterrompus. Ainsi, dans l'idée, avec un VPS très basique + un file-hoster tel que 1fichier (bien sur), il deviendrait alors possible pour moins de 3€/mois (oui, oui !) d'expérimenter pas mal de choses (pour déterminer par la pratique de quoi/combien j'ai vraiment besoin). Je me fais peut être un film, mais techniquement, ça me semblait jouable et j'ose imaginer mettre ça en place (ne serait-ce que pour le fun). J'imagine que ça serait dans tous les cas être assez sensible/capricieux, qui plus est avec les perfs de plus en plus réduites et aléatoires de 1fichier (de ce que je lis un peu partout)... ?

Et quid du s3fs & co sinon ? J'imagine qu'il y aurait encore plus de contraintes ?

Merci par avance pour vos réponses

Dernière modification par b1m2n3 (Le 24/07/2024, à 23:38)

Zakhar · Le 31/07/2024, à 15:27

b1m2n3 a écrit :

Tout d'abord, merci pour ce topic bien intéressant ; j'ai appris des choses, tant les explications y sont claires !

Merci, et merci aussi pour votre intérêt pour 1fichierfs ! Désolé pour la réponse tardive (vacances !).

b1m2n3 a écrit :

Concernant la forte contrainte apparue plutôt récemment de l'utilisation du crédit CDN lors de l'utilisation de l'API de 1fichier : y a t-il moyen d'empêcher cela ? Il a été question d'IPv6 comme solution potentielle en page précédente... Des retours à ce sujet ?
Pour ceux qui sont chez OVH par exemple, je sais que c'est possible d'office, dès les VPS premiers prix.

Non. Cette contrainte a sans doute été mise en place pour limiter les abus. En effet, le modèle économique de 1fichier repose à la fois sur le "partage" et sur un usage "domestique". Sans cela, il leur serait impossible de faire les prix actuels qui sont 50% moins chers que les "prix de marché" (voir premier post où je fais une "mini étude de marché"), et encore hors promotions en cours.

Egalement, les prix du stockage sur des serveurs en ligne (VPS ou mieux) sont aussi sans commune mesure avec un abonnement 1fichier. Aussi, utiliser ses "téra" 1fichier.com pour faire du "plex" (vous voyez ce que je veux dire... genre revendre le "service" à d'autres) ne serait pas très "fair use" par rapport au modèle économique actuel. L'infra de 1fichier.com est bien du partagé !
La parade a donc été pour eux de déclencher l'usage des CDN lorsqu'un usage "sur un serveur" est détecté.

L'histoire de l'IPV6, je n'en ai jamais eu confirmation auprès de ceux à qui j'ai donné le conseil. C'est juste une supposition de ma part. En effet, comment reconnaît-on que le trafic provient d'un "PC domestique" ou d'une "machine hébergé en ligne" ? Que l'on utilise le navigateur ou 1fichierfs (ou rclone), il n'y a pas de différence d'un point de vue serveur sauf l'adresse IP et potentiellement le "peering". Mais en général les "filtres" de ce genre reposent sur l'IPV4 parce la nature de l'IPV6 est différente et très variable. C'était donc juste une supposition (non confirmée) de ma part.
A vous d'essayer éventuellement... mais voyez bien que si trop de gens "contournent le modèle", 1fichier.com va réagir et filtrer sans doute aussi l'IPV6.

Pensez que je ne suis pas du tout affilié à 1fichier.com, je suis un simple client premium qui a écrit un "driver", en premier pour mon usage, et en open source pour qui veut l'utiliser.
1fichier.com n'offre aucune garantie sur mon driver, pas plus que sur rclone qui est une autre solution. Le seul moyen "supporté" par 1fichier.com est le navigateur, ou l'usage de l'API (curl par exemple).

Ce qu'il se passe côté serveur n'est pas (ou peu) documenté, de la sorte 1fichier.com peut changer quand il le veut sans préavis.
Les limitations que j'ai vues peuvent être constatées par n'importe qui d'un point de vue "client". Par exemple il y a une limite autour de 50 téléchargements en parallèle, et une limite des "tickets" de téléchargement. Ces limites là n'étant pas documentées, 1fichier.com est susceptible de les modifier à tout moment, notamment pour gérer les abus de certains... au détriment de ceux qui n'abusent pas !
Certaines limites sont documentées, par exemple on ne peut pas stocker un fichier de plus 300Go... mais la documentation peut également changer à tout moment... 1fichier.com donnera sans doute un préavis si cela doit être modifié.

Pour certaines limites, 1fichierfs dispose de moyens de secours en se comportant alors comme un navigateur au lieu d'utiliser les APIs, mais cela est alors plus lent. L'avantage est cependant d'éviter de planter/bloquer au détriment de la performance.

b1m2n3 a écrit :

Aussi, je suis intéressé par une petite mise au point sur les limites de 1fichierfs en matière d'écriture ? Au tout départ du projet 1fichierfs, j'ai cru comprendre qu'il n'était question que de lecture, puis que l'écriture a aussi été intégrée par la suite, mais toujours avec "limitation sur l'écriture aléatoire (overwrite)". Hors, si je ne me trompe pas, il me semble que l'écriture aléatoire est une chose, l'overwrite (qui peut être en séquentiel ?) en est une autre. Je ne suis pas expert sur la question, mais je cherche à déterminer quelles pourraient êtres concrètement les limitations pratiques...
Exemple : dans mon cas, j'avais projeté - dans un fort idéal - y faire pointer (avec ou sans stockage local intermédiaire) un gestionnaire de téléchargement, avec si nécessaire désarchivage dans la foulée (car ce dernier point, j'ai pu lire que c'était bien possible). Dans ce scénario, il ne s'agirait à priori que de transferts séquentiels ininterrompus. Ainsi, dans l'idée, avec un VPS très basique + un file-hoster tel que 1fichier (bien sur), il deviendrait alors possible pour moins de 3€/mois (oui, oui !) d'expérimenter pas mal de choses (pour déterminer par la pratique de quoi/combien j'ai vraiment besoin). Je me fais peut être un film, mais techniquement, ça me semblait jouable et j'ose imaginer mettre ça en place (ne serait-ce que pour le fun). J'imagine que ça serait dans tous les cas être assez sensible/capricieux, qui plus est avec les perfs de plus en plus réduites et aléatoires de 1fichier (de ce que je lis un peu partout)... ?
Et quid du s3fs & co sinon ? J'imagine qu'il y aurait encore plus de contraintes ?

L'écriture existe maintenant depuis un moment, et utilise le mode FTP... lequel présente des limites, notamment le temps de latence additionnel de 5 minutes (prévu pour les "reprises d'upload" mais que 1fichierfs n'utilise pas).
La limitation est effectivement de l'écriture (quasi) séquentielle. Cette limitation est due au fait que je souhaite conserver, en parallèle de 1fichierfs, le mode "standard", c'est à dire que les fichiers que vous uploadez seront toujours visibles en tant que fichiers portant le nom que vous leur avez mis, au travers de l'interface standard qui est le navigateur.
On pourrait en effet faire de l'écriture "aléatoire", cela consisterait à considérer le stockage distant comme un "périphérique de bloc", mais dans ce cas il faudrait toujours passer par 1fichiefs pour relire, et l'interface standard ne serait plus possible.

Le "quasi" séquentiel a été conçu spécialement parce que encfs (logiciel de chiffrement) que j'utilise par dessus 1fichierfs fait des overwrite de 8 octets tous les 1024 (ou 4096 selon paramètres). Donc en réalité l'écriture est "bufferisée" et on peut toujours "écrire en arrière" sur 64k.

Un gestionnaire de téléchargement avec désarchivage est effectivement "a priori" uniquement du séquentiel et devrait fonctionner... mais certains logiciels sont fort mal écrits et "s'amusent" à faire de l'aléatoire alors qu'en réalité ce n'est pas utile. Donc il faut toujours tester.

Je ne sais pas ou vous avez lu les "performances aléatoires" de 1fichier. Personnellement je considère que cela fonctionne de façon remarquable, surtout compte tenu du prix.
En lecture, j'arrive à saturer ma fibre (1Gbps) de Free sur un seul fichier (c'est à dire sans même du parallélisme) depuis mon PC qui a déjà quelques années (processeur Core i7 de génération 6, on en est à la 13 ou 14 !).
Pourtant, de ce que j'ai pu échanger avec la Team 1fichier, le peering avec Free n'est pas des plus faciles !..

Mais en réalité la performance est un tout et dépend aussi de votre machine, votre réseau, etc...
Ainsi, sur mon Raspberry Pi 4, j'arrive difficilement au tiers de la vitesse sur le PC, derrière la même freebox et avec le même câble Ethernet. Mais ça c'est dû au Raspberry Pi dont la puissance est limitée et qui peine dans le chiffrement (encfs ou tls).
Si vous aimez fonctionner en Wifi, ça affecte aussi la performance par rapport au bon vieux câble Gigabit Ethernet !

Les baisses de performances sur 1fichier.com sont rares. Ça arrive parfois sur certaines machines en particulier (donc une partie de vos fichiers) et c'est en général temporaire.
On peut aussi parfois constater des baisses générales de performances à certaines heures, mais n'oubliez pas qu'un abonnement fibre résidentiel est aussi partagé. Donc à l'heure où tout votre quartier aspire des tera octets pour regarde Netflix, Amazon Prime Video, Disney Chanel, ou simplement la télé en IP via sa box... eh bien oui, parfois on a des ralentissements. Je n'ose accuser 1fichier.com pour cela aussi !..

L'écriture est effectivement un peu plus lente. A Paris j'arrivais parfois à 45Mo/sec, en province où je suis mainenant à 21Mo/s. Beaucoup moins sur le Raspberry Pi, donc j'évite les uploads à partir de cette machine !.. Cela reste acceptable, à peu près la vitesse d'une "bonne clé USB2". Egalement, si on parallélise les écritures (jusqu'à 4 avec le driver actuel), on peut augmenter la vitesse totale d'upload. A Paris je parvenais à saturer la voie montant de la fibre ainsi avec plusieurs uploads en parallèle.
La différence en Paris/province prouve bien que le routage réseau joue aussi un rôle important, notamment sur l'upload. Sur ce facteur qui "accuser" ? Son fournisseur d'accès à internet, 1fichie.com, le complot mondial... bref vous voyez, la "performance" est un tout où de multiples facteurs rentrent en jeu !

Personnellement, je vous engage juste à essayer. Vous avez loupé la promo d'été à 20€ (au lieu de 30€)... j'en ai profité de mon côté pour me rajouter un an d'abonnement.
La "performance" sur un VPS risque effectivement de ne pas être au top, mais sans doute aussi bien pour des raisons CPU ou limitation de bande passante (partagée) comme je l'explique avec mon Raspberry Pi 4. Un VPS est sur une machine virtuelle avec un taux de partage important (pour arriver à faire un prix bas), et vous aurez donc sans doute des limitations davantage de ce côté là que du côté de 1fichier.com !..

s3fs, il y a déjà des drivers fuse qui existent, je n'ai donc pas exploré la chose, et si j'étais sur un stockage de ce genre (AWS), je regarderai en premier vers les drivers existants !
Il n'y a pas pas forcément plus de limites parce que de ce que crois comprendre s3fs est un "stockage d'objet" et non pas de fichiers. Ensuite la correspondance objets <> fichiers, si elle est nécessaire, est faite par le logiciel utilisé. On peut donc plus naturellement faire un "périphérique de blocs" j'imagine... enfin je n'ai vraiment pas creusé au delà de cette connaissance très superficielle.

Dernière modification par Zakhar (Le 31/07/2024, à 16:22)

b1m2n3 · Le 29/08/2024, à 18:48

Merci pour cette réponse ! Et désolé aussi pour ma réponse tardive aussi

Au vu de ce que je lis, je n'ai au contraire rien raté du tout ! Le service proposé est beaucoup trop dirigé pour du partage de masse et ce n'est pas ce que je cherche... Je voyais si je pouvais écrire de gros fichiers depuis un VPS puis les récupérer assez classiquement sous un délai assez court, pour mon usage exclusif. J'abandonne donc cette piste avec 1fichier & co, trop incertain et volatil dans le fonctionnement et conditions d'utilisation. Et même donné, même pour un usage plus simple, ce service ne m'intéresserait toujours pas vu l'absence totale de garantie de retrouver ses données une semaine après ou même le lendemain après les y avoir déposé !

En revanche, peut-être que j'essaierais avec du stockage type bloc/objet, pas si restrictif qu'il n'y paraitrait selon moi... Sinon j'avais aussi pensé essayer avec un service S/FTP/S "augmenté", notamment celui proposé par Hetzner (uniquement eux semble t-il, pas trouvé d'équivalent) : https://www.hetzner.com/storage/storage-box/bx11/. A priori, leur service est assez souple pour être "Usable as network drive", donc pour usage convoité, et plutôt bon marché je trouve. Vous pensez que ça peut le faire avec un driver fuse ou autre, ou je me fais une fausse idée et il vaudrait mieux que j'évite de m'y casser les dents ?

Merci encore !

Dernière modification par b1m2n3 (Le 29/08/2024, à 18:52)

Zakhar · Le 29/08/2024, à 20:54

C'est toi qui vois !

Je dois être super chanceux, personnellement je n'ai jamais perdu aucun fichier avec 1fichier.com.
Il m'arrive, mais vraiment très rarement, d'avoir des ralentissements, mais c'est toujours passager.

Hetzner n'est sans doute pas le moins cher, ça fait du 46€/an pour 1TB, d'autres proposent du 2TB pour 60€. Cependant effectivement, ça a l'air souple. En fait si tu utilises SAMBA/CIFS, ce sera transparent. La dernière fois que j'ai utilisé CIFS, c'était effectivement un driver fuse, il est dans les dépôts d'Ubuntu, pas de tracasserie c'est du "standard" !..

Et effectivement, le modèle de 1fichier.com est bien le "partage de masse", raison pour laquelle ils peuvent faire ce prix imbattable (en tout cas imbattu !) et c'est sage de ne pas les utiliser pour autre chose.
Ils n'ont cependant pas de problème avec le "Cold storage", c'est à dire les "backups" (j'ai plusieurs séries de backups de mes divers PC), ainsi que toute ma musique numérisée, ce qui m'évite de ressortir les CD (et de toute façon je n'ai plus de lecteur de CD !). Tout ça est dans leurs conditions d'usage.

Dernière modification par Zakhar (Le 29/08/2024, à 20:55)

Jarodd · Le 06/09/2024, à 08:49

Bonjour,
Juste pour dire que j'ai été quelques mois chez Hetzner. J'en suis vite reparti, les débits sont catastrophiques, et le support ne répond pas.
Cerise sur le gâteau, quand j'ai résilié ils ont continué à me réclamer des paiements (heureusement je payais en CB et pas en prélèvement).

z3ndra · Le 13/09/2024, à 21:59

Salut. Sais tu quand sortira la prochaine mise à jour par hasard ? Car le volume se retrouve corrompu plusieurs fois, je ne sais pas trop pourquoi mais par moment c’est comme si son contenu devenait inaccessible, je suis obligé de le demonter puis le remonter pour que tout revienne comme avant. Merci d’avance ?

Zakhar · Le 13/09/2024, à 23:12

Oui Z3ndra, il y a un bug connu. Les fichiers ne sont pas "corrompus" mais parfois la version actuelle se plante, et il n'y a effectivement pas d'autre solution que de tuer le process et relancer.

C'est corrigé depuis un moment chez moi, mais je n'ai pas encore eu le temps de packager, beaucoup de travail et d'activités à côté.

Le github est à jour cependant, tu peux compiler la dernière version corrigée depuis celui-ci. Comme je rentre, en plus du travail, dans un période de travaux au domicile de ma mère, je ne suis pas sûr d'avoir le temps de faire la package de si tôt hélas.

Mais je note ta demande, comme jusqu'à présent personne n'avait rien dit je présumais que ça ne gênait pas, et je vais monter la priorité de cette tâche.

Aussi, il va falloir que je rajoute la version packagée pour 24.04 en espérant que le tuto antique que j'ai suivi y fonctionne toujours !

Dernière modification par Zakhar (Le 13/09/2024, à 23:15)

z3ndra · Le 22/09/2024, à 13:12

Ca marche merci pour ta réponse, je vais plutot attendre la version packagée ça sera plus simple. Vraiment hate. Apres en attendant j’ai mit un script qui verifie l’accessibilité d’un fichier toute les 10 min et si il est inaccessible parce que ça a planté, ca le demonte et le remonté automatiquement mais ça reste relou lol

z3ndra · Le 26/09/2024, à 12:06

salut, j'ai aussi remarqué un truc , c'est que 1fichierfs se met a consommer enormement de ressources cpu, ce qui freeze le serveur à la longue.

Zakhar · Le 09/10/2024, à 23:25

Oui @z3ndra !
Ça fait partie du bug connu. Quand le bug se produit, ça peut planter, mais aussi les requêtes peuvent se mettre à tourner sans fin entre les threads, et du coup ce n'est pas planté, mais le fichier qui était lu est bloqué, et le CPU monte en flèche à cause du passage en boucle sans fin entre threads. Dans ce cas là : kill + fusermount -u

Il est possible que l'option -o sync_read fasse disparaître le bug puisqu'il se produit quand on a plusieurs requêtes en parallèle a début d'un fichier, mais cela peut aussi avoir un impact sur la performance... à tester donc !

Je viens de faire le dernier test qui nécessite de changer un paramètre interne pour forcer certaines choses à se produire, et ça fonctionne comme prévu.
J'ai "taggé" la version 1.9.5 sur le gitlab, elle est prête pour la release.

Je vais mettre à profit la grippe/arrêt de travail pour tâcher de vous packager cette 1.9.5 qui corrige ces méchants bugs de synchro.
Aussi elle apporte la "log circulaire" que j'ai mise en place précisément pour attraper ce bug de boucle infini. La log étant vite pleine en mode debug, je n'avais pas la "fin". Avec le système circulaire, si on tue le programme suffisamment vite quand la boucle infinie se produit, on peut avoir l'instant qui a déclenché la boucle-bug.

Aussi il va falloir que je songe à 2 trucs pour le futur :
- déprécier la 16.04, en effet elle oblige à maintenir des paramètres de compilation spécifiques (gnutls au lieu de openssl)
- regarder fuse 3 qui est le fonctionnement par défaut au moins sur la 24.04 (et peut-être déjà en 22.04 !). Fuse 2 est toujours supporté bien sûr... heureusement !

Dernière modification par Zakhar (Le 10/10/2024, à 00:01)

Zakhar · Le 10/10/2024, à 16:40

(10 octobre 2024) Version 1.9.5

Nouveautés par rapport à la 1.9.4

Fix bugs/crashes : crash ou boucle infinie (avec forte consommation de CPU) lors d'inversion des premières requêtes de lecture d'un fichier.
Fix bugs/crashes : crash/bug théorique quand un fichier est abandonné (time out interne) et au même moment rouvert.
Nouvelle LTS : le logiciel est désormais également packagé pour la dernière LTS : Noble Numbat - 24.04.
Fonctionnalité : possibilité de limiter la taille du fichier journal, lequel devient alors un journal "circulaire" (mode debug uniquement).
Documentation : mise à jour de la documentation en 1.9.5.

Mise à jour
Le crash ou boucle constaté a d'autant plus de chance de se produire qu'on ouvre beaucoup de fichiers.
Même si vous ne l'avez jamais constaté, il est plus prudent de faire la mise à jour.

A noter que le package standard ne comportant pas la fonctionnalité "DEBUG", vous n'avez pas la nouvelle fonctionnalité "journal circulaire" puisque elle n'est vraiment nécessaire que dans ce mode là. Cette fonctionnalité, si vous la souhaitez, nécessite donc que vous compiliez vous-même le package depuis le gitlab, et que vous lanciez le driver en mode verbosité 7 (--log-level 7)
L'aide (1fichierfs -h) n'indiquera pas la nouvelle fonctionnalité puisqu'elle n'est pas disponible hors DEBUG, par conte le "man" vous l'expliquera avec cette limitation.

Pistes futures (sans urgence) :
- Déprécier 16.04 et 18.04 qui nécessitent une fabrication particulière avec gnutls au lieu de openssl
- Regarder les nouvelles fonctionnalités de Fuse 3. Si elles présentent un intérêt pour 1fichierfs, les implémenter. En effet, en 24.04 Fuse 3 est le standard au lieu de Fuse 2 (toujours supporté)
- Améliorations diverses.

Pour Raspberry Pi, je vais désormais fournir le package 64 bits Bookworm. Pour Buster 32 bits, vous pouvez compiler depuis le source.

Raspberry Pi OS (Bookworm 64 bits): 1fichierfs_1.9.5~bookworm-1_arm64.deb

stat -c "%s %n" 1fichierfs_1.9.5~bookworm-1_arm64.deb; sha256sum 1fichierfs_1.9.5~bookworm-1_arm64.deb; md5sum 1fichierfs_1.9.5~bookworm-1_arm64.deb 
103404 1fichierfs_1.9.5~bookworm-1_arm64.deb
0d0efc83bd6957983764f5aa894c7152daebfaea7fe57b39add628972bbfe5bd  1fichierfs_1.9.5~bookworm-1_arm64.deb
b588cb71a14e81012257531109b82f17  1fichierfs_1.9.5~bookworm-1_arm64.deb

Dernière modification par Zakhar (Le 11/10/2024, à 08:52)

Zakhar · Le 10/10/2024, à 23:53

z3ndra a écrit :

salut, j'ai aussi remarqué un truc , c'est que 1fichierfs se met a consommer enormement de ressources cpu, ce qui freeze le serveur à la longue.

La nouvelle version devrait améliorer tout ça. N'oublie pas, après la mise à jour en 1.9.5 de faire un fusermount -u si le stockage distant était monté avant la mise à jour, puis monter à nouveau le stockage distant pour que la nouvelle version soit prise en compte.

Si tu vois d'autres bugs, n'hésite pas à prévenir, chez moi ça tourne sans aucune anomalie sur mon PC principal et mon Raspberry Pi depuis au moins 1 mois.

Dernière modification par Zakhar (Le 11/10/2024, à 08:53)

Zakhar · Hier à 10:20

Dans les améliorations diverses, j'en ai 2 en tête :
- Permettre un téléchargement via Firefox directement sur le montage. Après examen, il semble que parfois firefox ferme le fichier local puis le réouvre pour continuer le téléchargement. Le mode "append" n'étant pas prévu pour le moment, cela échoue.
- Permettre à encfs de renommer un fichier. En effet, le renommage sur encfs provoque le changement de 8 octets en tête du fichier qui contient en gros la clé permettant de déchiffrer. Comme l'overwrite est interdit, cela ne fonctionne pas. J'ai en tête une "astuce" pour que cela soit possible dans la majorité des cas si un sous-répertoire est déclaré géré par encfs.

Dernière modification par Zakhar (Hier à 15:17)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#501 Le 21/07/2024, à 23:27

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

#502 Le 21/07/2024, à 23:58

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

#503 Le 22/07/2024, à 08:34

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

#504 Le 24/07/2024, à 23:31

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

#505 Le 31/07/2024, à 15:27

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

#506 Le 29/08/2024, à 18:48

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

#507 Le 29/08/2024, à 20:54

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

#508 Le 06/09/2024, à 08:49

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

#509 Le 13/09/2024, à 21:59

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

#510 Le 13/09/2024, à 23:12

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

#511 Le 22/09/2024, à 13:12

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

#512 Le 26/09/2024, à 12:06

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

#513 Le 09/10/2024, à 23:25

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

#514 Le 10/10/2024, à 16:40

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

#515 Le 10/10/2024, à 23:53

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

#516 Hier à 10:20

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

Pied de page des forums