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

Zakhar · Le 21/05/2020, à 16:09

(21 Mai 2020) Version 1.7.1.1

Nouveautés par rapport à la 1.7.1

Patch : statfs retourne désormais la longueur maximale des noms de fichiers, soit 250 (maximum accepté par 1fichier.com). Sans cela Nautilus (20.04) refusera de renommer un fichier ou créer un répertoire.
20.04 : build avec OpenSSL (au lieu de GNUTLS en 16.04).

Mise à jour ?
La mise à jour ne concerne que la 20.04
Si vous avez une version antérieure, le patch (1 ligne de code !) n'a pas d'urgence, il sera donc fait avec les prochaines MàJ.
Le paquet étant livré seulement pour la 20.04, si vous avez une version antérieure, il n'y a pas de mise à jour de 1fichierfs.

Dernière modification par Zakhar (Le 21/05/2020, à 16:10)

math.hdr · Le 18/09/2020, à 20:04

Salut, merci pour 1fichierfs qui fonctionne pour moi à merveille, je me pose une question, étant sous Ubuntu 18.04 LTS et ayant telechargé 1fichierfs depuis le ppa est-ce que la connexion entre les serveurs 1fichier.com et mon pc est chiffré et si oui par quelle protocole ?
Merci, beaucoup pour tout ce savoir partagé !

Zakhar · Le 18/09/2020, à 20:33

Bonjour Math.hdr.

Et merci de ton intérêt pour 1fichierfs.

Réponse courte : oui !.. ('tout chiffrer" est le comportement par défaut)
Protocoles https pour tout ce qui est en http (appels à l'API et lecture des fichiers), et ftp sécurisé pour tout ce qui est ftp (upload/ quand tu écris sur le montage).
1fichierfs utilise exactement les mêmes accès que ce que tu ferais "à la main" en téléchargeant tes fichiers avec ton navigateur et en uploadant avec ftp (filezilla par exemple).

Réponse longue :
- les appels à l'API sont TOUJOURS chiffrés car l'API fonctionne exclusivement en https.
- pour les accès aux fichiers, en réalité cela dépend... de ce que tu veux toi !..

Développons...
Le mode "par défaut" chez 1fichier.com est d'utiliser https, c'est à dire une communication chiffrée. Cependant le chiffrement a un impact sur les performances. Par exemple, sur mon Raspberry Pi 4, je peux faire du 100Mo/s en http non chiffré, mais je plafonne à 45 ou 50Mo/s en https (chiffré). Donc pour des raisons de performance, l'utilisateur peut avoir envie de ne rien chiffrer du tout.

Pour cela il existe un paramètre global dans ton interface web sur 1fichier.com, à la rubrique "Paramètres" qui s'appelle "Forcer le téléchargement non SSL".
Si tu coches ce paramètre, tous les liens présentés par 1fichier seront en http simple et donc non chiffrés, que tu utilises simplement ton navigateur sur l'interface de 1fichier.com, ou que tu utilises 1fichierfs.
Ce paramètre s'applique à TOUT ton stockage puisqu'il est géré au niveau du serveur.
Si tu crains d'être en "non chiffré", vérifie bien que tu n'as pas coché cette case !..

Ensuite il peut y avoir d'autres cas où tu n'as pas besoin du chiffrement. Dans mon cas par exemple, j'ai certains fichiers "personnels" qui sont stockés sur mon compte et ils sont chiffrés à partir de mon PC avec encfs. encfs est monté "par dessus" 1fichierfs, et ça marche parfaitement !.. Plus amusant, dans la partie chiffrée j'ai des ISO, je peux aussi les monter par simple clic, donc "empiler" 1fichierfs/encfs/montage_ISO... De la sorte ce qui est stocké sur la partie géré par encfs est un fichier déjà chiffré, et le nom du fichier est également chiffré. Ainsi, le fournisseur de stockage (DStorage/1fichier.com) ne peut pas voir ce qu'il y a dans mes fichiers. Il voit juste des fichiers avec des noms étranges contenant des suites d'octets sans signification. Cela prévient une fuite chez le fournisseur : employé indélicat, failles ou attaques du fournisseur, injonction d'organismes officiel de communiquer des fichiers, etc...
Comme ces fichiers sont déjà chiffrés en contenu et en nom, il devient alors inutile d'utiliser https pour ces fichiers là puisque cela ferait du "double chiffrement". On ne fait que perdre de la performance.

Plus simplement tu peux avoir des fichiers qui n'ont pas besoin d'être chiffrés, comme par exemple si tu stockes des images ISO des tes distributions Linux favorites (fichiers totalement publics !).

Pour gérer ces deux cas (et sans doute d'autres) il existe une façon de dire à 1fcihierfs de ne pas chiffrer seulement pour certains répertoires (et leurs descendants).

Il s'agit de l'option --no-ssl

Tu peux consulter le manuel qui est inclus dans le package pour cette option :

$ man 1fichierfs

(...)
 --no-ssl=chemin
              Par  défaut,  les téléchargements se font avec ou sans SSL/TLS selon le réglage no_ssl de chaque fichier individuel. Indépendamment de ces réglages, spécifier cette option force la désactiva‐
              tion de SSL/TLS pour toute l'arborescence sous chemin. Utiliser cette option évite d'avoir à régler individuellement le paramètre no_ssl de chacun des fichiers de  toute  l'arborescence  sous
              chemin.

              Cette option peut apparaître plusieurs fois pour spécifier différents chemins.
              Usage typique : quand les fichiers et noms de fichiers sont déjà chiffrés, lorsqu'une machine peu puissante est utilisée et que SSL/TLS est lent (au détriment de la sécurité/vie privée).

Exemple pratique, tu as
- Un répertoire où sont stockés des fichiers déjà chiffrés : Crypt
- Un répertoire où sont stockés des fichiers complètement publics (ISO d'Ubuntu !) : Public

Tu peux alors lancer 1fichierfs avec

1fichierfs --api-key="ta_clé_api" /path/to/mountpoint --no-ssl=/Crypt --no-ssl=/Public

Ainsi, tout sera chiffré sauf le contenu des deux répertoires ci-dessus (et de leurs éventuels sous répertoires de façon récurrente).

Signalons aussi pour être complet qu'on peut changer l'attribut SSL au niveau de chaque fichier... au travers de l'API, mais je n'ai pas trouvé la façon de le faire via l'interface web standard.
Donc si tu as mis "no-ssl" sur certains fichiers en appelant l'API qui convient (toi-même, car 1fichierfs ne se permet pas de changer cet attribut du fichier !), ces fichiers là seront bien en no-ssl (non chiffrés) qu'ils aient été spécifiés sur la ligne de commande 1fichierfs ou pas, à l'image du non-chiffrement global par le paramètre "Forcer le téléchargement non SSL".

En complément, l'upload (tu peux aussi "écrire" sur ton montage, avec les limitations classique indiquées dans le manuel !) se fait toujours en FTP sécurisé, sauf pour les répertoires que tu as explicitement déclarés en --no-ssl
Dans ce dernier cas, la non-sécurisation concerne bien sûr uniquement la partie "données" du fichier, le préambule de connexion à FTP est lui toujours chiffré, sinon on pourrait voir ta clé d'API en clair !..

Résumé :
En espérant que ces explications sont claires... tu peux retenir la réponse "oui", si tu as bien vérifié que tu n'avais pas coché "Forcer le téléchargement non SSL" dans les paramètres de ton compte !..

P.S.: merci pour la question, je vais clarifier le manuel car mentionner l'option no_ssl au niveau de chaque fichier n'est pas le plus essentiel car faisable uniquement si l'utilisateur est déjà familier avec l'API !.. Il vaut donc mieux que je mentionne le "paramètre global". Je vais aussi rajouter un bref mot sur l'upload, car le texte date de l'époque où l'écriture n'était pas encore développée.

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

math.hdr · Le 19/09/2020, à 10:45

Merci pour cette réponse clair et détaillé, c'est vrai qu'il serait très intéressant de combiner 1fichierfs et un système de chiffrement local comme encfs pour rendre privé les donnée mais j'ai alors quelques questions qui me viennent en tête:

Si j'ai beaucoup de fichiers en 1080p (plusieurs terra) a monter/déchiffrer et que je souhaite dès le démarrage pouvoir les lire, ne vas-t'il pas y avoir un "temps" durant lesquels je ne pourrais pas accéder au contenu ( le temps que tout soit déchiffré)?
Est-ce qu'une Raspberry suffirait en terme de puissance de calcul pour tout déchiffrer de façon rapide ?

Autres question en lien avec 1fichierfs:

Y a t-il une limite en temps de visionnage
Y a t-il une limite de visionnage simultanée ( pour le même serveur)

Zakhar · Le 19/09/2020, à 11:18

Bonjour Math.hdr

Non, avec encfs il n'y a aucun "temps de démarrage" puisque c'est aussi un montage fuse qui est capable de lire des bouts du fichier. Le processus n'est pas de télécharger tout le fichier, déchiffrer et commencer, tout se fait "à la volée". Tu peux par exemple même sauter à un endroit sur film sans aucun délai, encfs + 1fichierfs ou pas !..

Par contre, quand tu écris des fichiers sur le montage (ce qui se traduit par un "upload" pour 1fichier.com) il y a un temps de latence avant que le fichier devienne disponible à la lecture, bien que 1fichierfs t'affiche directement le fichier que tu viens d'uploader. Ce temps d'indisponibilité est du aux contraintes techniques imposées par 1fichier. Il faut compter à la louche 5 minutes + 30 secondes par giga. Les 5 minutes sont dues à la façon dont fonctionne le ftp chez 1fichier.com.

Un Raspberry Pi 4 avec un O.S. 32 bits (Raspbian) est suffisant pour visionner avec Kodi du "BluRay 1080p" (c'est à dire en format 25 à 50Go) stocké en encfs + 1fichierfs.
Pour le 4K, indépendamment du stockage et de la lecture... il faudra attendre un O.S. 64bits pour espérer avoir quelque chose d'utilisable sur Raspberry !..
Il faut bien sûr la connexion internet adaptée... la Fibre de Free est excellente pour ça, et on arrive à la saturer à 1Gpbs avec 1fichierfs parce que le service de 1fichier.com est excellent aussi. Néanmoins, comme expliqué dans le post précédent, on ne parvient pas à saturer à 1Gbps avec chiffrement sur un Raspberry Pi 4 avec version 32 bits. Mais c'est lié à la limitation de puissance du Pi.

Et non, il n'y a pas de "limite de visionnage" puisque 1fichier.com ne voit pas ce que tu fais avec ton fichier. Un fichier accédé au travers de 1fichierfs est équivalent à un "download" pour 1fichier.com
Et comme tu n'as pas de limite de download (seule ta bande passante limite) tu fais ce que tu veux.
D'ailleurs si les fichiers sont stockés en "encfs", ce que vois 1fichier.com c'est que tu récupères un fichier avec un nom bizarre et un contenu chiffré. Ce que tu fais de ce que tu as récupéré se passe sur ton PC et donc hors de la vue de 1fichier.com
Du reste si ça a été fait via encfs, 1fichier.com ne peut même pas dire s'il s'agit d'un film, d'un ISO Ubuntu, d'une sauvegarde de tes disques, etc... Ils voient juste un fichier d'une certaine taille. Bien sûr un fichier de 10Go est rarement une image JPEG. :-p

La limitation imposée par 1fichier est que tu n'utilises pas plusieurs adresses IP en même temps (pour éviter les abus et "partager" ton abonnement avec toute ta famille et amis !)

Donc pour un usage "familial" au sein de ton domicile avec une seule IP, si tu as 3 PC tu peux regarder un film sur chacun, ça ne posera pas de problème !..
Dans ce cas, il vaut mieux fixer l'IPV4 au lancement de 1fichierfs car si tu as ipv4 et ipv6 (Free propose ça par exemple), le kernel choisira souvent plutôt ipv6 et du coup tes 3 PC auront 3 IP différentes vues de 1fichier.com et seul le premier qui a commencé aura droit à regarder le film !..

Pour fixer ipv4 rajoutes l'option -4 dans la ligne de commande.

Après si la question est sur le PC lui-même, sans aller jusqu'à avoir plusieurs PC connectés à une Box, oui tu peux regarder plusieurs films, ou télécharger plusieurs fichiers à la fois.
1fichierfs est compilé avec 4 "readers" (non paramétrable sauf en recompilant toi-même). Ce qui veut dire que jusqu'à 4 flux en parallèle, ce sera très fluide (tant que tu as de la bande passante !)
Au delà de 4 flux, il n'y aura pas de blocages, mais 1fichierfs va commencer à faire des lectures par morceau "non stream" et la performance va être assez catastrophique rendant le visionnage de film aléatoire...

Mais bon, je ne pense pas que tu aies besoin de visionner plus de 4 films en même temps sur le même PC... ou récupérer plus de 4 sauvegardes en parallèle !..
Pour ce qui est du visionnage sur des PC distincts, il n'y a pas de problème puisque chacun aura son 1fichierfs.

Après tu peux être imaginatif, te servir du Raspberry avec minidlna pour servir ta vidéothèque à ton Freebox Player (UPNP AV). Et si tu as plusieurs Freebox Player, servir plusieurs films en parallèle sur ceux-ci. La limitation sera alors la puissance de Rasp pi.

Dernière modification par Zakhar (Le 19/09/2020, à 11:25)

math.hdr · Le 19/09/2020, à 11:42

Ok, merci c'est parfait du coup il faut que je regarde pour encfs alors !
Si j'upload sur mon serveur avec remote upload (avec http ) les fichiers seront en clair, il faudrait alors attendre que mon pc soit connecté pour que les fichiers soit chiffrés, et cela prendrait 5min 30 par go si j'ai bien compris ?
Est-ce que passer par un serveur qui chiffrerait les fichier avant de les mettre sur le serveur 1fichier.com pourrais régler le problème du temps d'attente?
Et ma dernière question, a quoi sert l'offre CDN de 1fichier.com s'il n'y a pas de restriction de téléchargement ?

En tout cas merci de prendre du temps pour répondre a mes questions !

Zakhar · Le 19/09/2020, à 12:58

Ce sont plutôt des questions sur le service 1fichier.com que tu poses... mais comme j'ai beaucoup échangé avec eux je peux y répondre, dans la seule limite où leur politique technique et commerciale est à leur main et peut changer quand ils le veulent.

Remote upload : que ce soit en http ou https, le fichier est de toute façon "en clair" pour 1fichier.com. La différence est que si tu fais du remote upload http, tous les routeurs entre ta cible de remote et 1fichier.com voient le fichier en clair. Ensuite le fichier sera stocké sur ton compte 1fichier.com, et sera accessible via ton navigateur ou via 1fichierfs en https par défaut (sauf tu as changé de ce paramètre dans l'interface "Paramètres" de ton compte 1fichier.com). De ce point de vue, ça ne fait aucune différence que le fichier ait été uploadé en ftp, http ou remote, et que le mode d'upload ait été sécurisé ou pas.

Dans tous ces cas, 1fchier.com voit ton ficher en clair (sauf si tu l'as chiffré avant upload : encfs ou autre solution)

Rien ne peut régler le "temps d'attente" hélas !..
Pour les 5 minutes propres à FTP, la team 1fichier accepté mon idée de pouvoir les éviter en mode API... mais cela est dans leur "todo-list" en priorité très très basse. Donc je ne m'attends pas à ce que soit fait demain, surtout que ça fait bien 1 an que c'est dans leur "todo list" !..
Pour les autres temps (30 sec par Giga environ), ils sont indépendants du mode d'upload et à peu près incompressibles. Ils peuvent néanmoins diminuer un peu au fil du temps, quand 1fichier.com remplacera ses serveurs par des serveurs plus puissants. En effet, pour des raisons de sécurité, tout upload (ftp, http ou remote) chez 1fichier se fait dans une "zone temporaire". Il faut donc ensuite le temps de recopier le fichier de la "zone temporaire" au "storage" (temps brut de copie physique dépendant surtout de la taille du fichier) et une fois sur le "storage", certaines vérifications sont faites donc la checksum Whirlpool (et éventuellement antivirus ?)... ça c'est de la "cuisine serveur" et on ne peut que "supposer". Mais cette "cuisine serveur" prend aussi un peu de temps. Au total, "copie physique + cuisine serveur", c'est environ 30 sec par Giga.

Donc l'espoir est un jour de pouvoir gagner ces 5 minutes par fichier, mais le temps incompressible restera de toute façon.

1fichierfs ne peut pas utiliser un autre mode que ftp pour l'upload, de par son architecture.
Par contre rclone qui rend des fonctions similaires (sans doute moins poussées pour 1fichier.com) fait l'upload en http, mais en "trichant" puisque le fichier à uploader est d'abord copié en local !..
C'est une décision d'architecture. 1fichierfs n'ira jamais dans cette voie là. 1fichierfs n'a absolument pas besoin d'espace local que ce soit pour lire ou pour écrire des fichiers, ce qui me permet de manipuler des images de BluRay (50Go) avec mon Raspberry Pi dont le seul stockage est la carte SD de 16G0 !..

Tu peux bien sûr copier les fichiers "à la main" sur un espace local, et ensuite, au travers de 1fichierfs les uploader, ce qui se fait à la souris, comme si tu copiais un fichier sur une clé USB. 1fichierfs utilisera néanmoins ftp, car il n'a aucun moyen de savoir si le fichier est stocké en local, ou arrive en "stream" par exemple via curl.

L'offre CDN sert pour partager les fichiers à d'autres sans restriction, surtout quand ces "autres" ne sont pas clients payant de 1fichier.

Exemple, puisqu'on parle de film, tu as pris un film des premiers pas de tes enfants, et tu veux le partager avec tes parents, oncles et tantes.
Tu stockes le film sur 1fichier.com (simple copie avec 1fcihierfs)
Et ensuite tu envoies le lien à ta famille.

Mais le problème c'est que toi tu es abonné, mais pas eux !.. Ils vont donc avoir un service pas terrible réservé aux non abonnés avec attente, téléchargement lent, etc...
Pour régler cela, tu colles des "CDN" sur le film de tes enfants en question, et ta famille pourra voir le film comme si ils étaient eux-même Premium... jusqu'à ce que ton quota de CDN soit épuisé !..

Ça c'est l'usage typique...
Après tu peux aussi t'en servir pour toi-même. Tant que tu es abonné, ça ne sert à rien. Mais si tu décides de ne pas poursuivre ton abonnement, tu auras tout de même gagné des "CDN gratuits", tu pourras alors les mettre sur les fichiers qui t'intéressent pour les downloader sans limitations... jusqu'à ce que ton crédit de CDN soit épuisé.

Attention cependant, tu ne pourras plus utiliser 1fichierfs si tu n'es plus abonné puisque l'API ne fonctionne que pour les "access et premium". Les CDN devront donc être utilisés de la manière "classique". Si par exemple tu veux regarder un film, il faut commencer par le télécharger (donc perte de temps avant de commencer à regarder)... contrairement à ce que tu peux faire avec 1fichierfs où c'est comme si tes films étaient sur une clé USB.

Dernière modification par Zakhar (Le 19/09/2020, à 13:04)

math.hdr · Le 20/09/2020, à 17:26

Merci beaucoup pour tout ces renseignements je vais essayer de faire quelque chose avec encfs je pense...

Zakhar · Le 20/09/2020, à 17:53

Pour le bon usage de encfs dans ce cas, il faut que tu conserves le fichier de clé (encfs6.xml) en local, car si tu le mets sur le stockage distant, ça donne plus d'éléments pour "craquer" tes fichiers.

Donc tu commences par créer ton encfs

encfs /path/to/encrypted /path/to/decrypted

... avec les paramètres qui te conviennent (ne pas oublier que encfs prend des chemins absolus !)
Une fois ceci créé, tu récupères le fichier caché .encfs6.xml qui se trouve dans le répertoire encrypted, et tu le stockes quelque part en local.
Personnellement, il est dans mon /home sous le nom : /home/zakhar/.config/.1fichier_encfs6.xml

IMPORTANT : pense à en faire une sauvegarde (ou même 2 !) parce que sans ce fichier tu ne peux plus rien déchiffrer !..

Une fois ceci fait tu lances encfs ainsi :

ENCFS6_CONFIG=/home/zakhar/.config/.1fichier_encfs6.xml  encfs /home/zakhar/1fichier/.crypt/ /home/zakhar/Secure/

Dans l'exemple ci-dessus, encfs va :
- utiliser le fichier encfs6.xml qui est en local sur le PC grâce à la variable d'environnement ENCFS6_CONFIG
- chiffrer les fichiers dans /home/zakhar/1fichier/.crypt/ donc un répertoire qui est sur le stockage 1fichier.com (ce qui suppose que tu as monté au préalable /home/zakhar/1fichier avec 1fichierfs)
- présentera le résultat "en clair" dans le répertoire /home/zakhar/Secure/

On n'utilise que ce dernier répertoire pour lire et écrire. Le répertoire "chiffré" est un répertoire "technique".

Limitations dues au fait que le mode d'écriture ne se fait qu'en "une seule fois" : pas d'append, pas d'overwrite
- (il est possible que) tu ne puisse pas renommer ou déplacer un fichier dans l’arborescence sécurisée, car cette opération peut faire un "overwrite" du début du fichier.
- (il est possible que) tu ne puisses pas renommer ou déplacer un répertoire dans cette arborescence si celui-ci a des descendants qui sont des fichiers pour la même raison.

(il est possible que) car dans le mode conseillé "paranoïa", le chemin du fichier sert d'initialisation pour la clé aléatoire. Donc si un des éléments du chemin change, la clé change et il faut réécrire une partie du fichier.
Si tu n'utilises pas cette fonction d'initialisation par rapport au chemin du fichier (déconseillé car c'est moins sécurisé puisqu'alors des fichiers qui ont le même nom dans des répertoires différents vont partager des caractéristiques communes) alors les limitations sautent.

Avertissement modèle économique !
Si 1fichier.com peut faire les prix qu'on connaît (les meilleurs au monde actuellement !) c'est parce que pour l'essentiel ce service est utilisé pour du "partage social" de fichiers.
Ce qui veut dire qu'un fichier de 10Go qui a été partagé 1000 fois, n'utilise pas du tout 1000 x 10Go = 1To, mais utilise en fait 10Go et des broutilles.
En effet, seul le premier qui upload le fichier "consomme" du disque. Les autres qui utilisent le partage ont simplement une URL qui pointe sur le même fichier.

Par contre quand on utilise 1fichier.com pour ses propres sauvegardes (ou via encfs ce qui revient au même puisque personne ne sait ce que vous avez "sauvegardé") il s'agit de fichiers uniques et non partagés.
Si chacune des 1000 personnes ci-dessus recopiait le fichier de 10Go dans un espace personnel sécurisé (encfs), le total ferait bien 1To puisque chaque exemplaire de fichier stocké serait différent à cause de l'aléa de la clé de chiffrement.

La team 1fichier a "pris le risque", et autorise explicitement que vous fassiez vos "propres sauvegardes" sur ses serveurs. Et donc qu'il y ait des fichiers "non partagés".
Pour limiter cela, il y a le fonctionnement en Cold/Hot. Donc un fichier qui vous est propre et qui ne bouge pas, au bout d'un moment -60 jours, voir CGU- va consommer du "Cold" et c'est ce quota là qui vous est décompté, le "Hot" étant lui illimité.

Utilisez donc cette fonction de "sauvegarde personnelle" avec raison, car elle fait baisser le facteur de "dé-duplication" et si ce facteur baisse trop, les prix auront forcément tendance à rattraper "ce qui se fait" sur le marché, le moins cher étant à 3 fois le prix de 1fichier (voir page 1, à la date d'actualisation, kDrive Infomaniak était le 2ème moins cher avec 60€/an pour 2To) !

NOTA :
En préparation, une version qui garde en mémoire les petits fichiers (moins de 4096 octets) qui ont été écrits tant qu'ils ne sont pas sur le stockage.
Cela permet de mieux gérer la "corbeille" avec Nautilus car les fichiers d'information qui indiquent où était le fichier supprimé (mis dans la corbeille en fait) sont dans ce cas.
Le fonctionnement de la "corbeille" sur les fichiers de votre compte 1fichier.com devrait donc être amélioré avec la prochaine version en préparation !
Attention cependant, un fichier mis dans la corbeille utilise toujours du stockage... puisqu'il est toujours là en fait !

[Edit] 1.7.2 avec la modification ci-dessus et quelques améliorations de documentation (manuel : man) suggérées par les questions récentes, est en cours de test sur mes PC. Pour bientôt en package si tout va bien.

Dernière modification par Zakhar (Le 22/09/2020, à 21:24)

Zakhar · Le 26/09/2020, à 12:26

Non, je n'ai pas arrêté le développement de 1fichierfs... j'étais juste en vacances, et ça fonctionne "suffisamment bien" pour que le reste soit du "nice to have". Il y a cependant des "bugs connus" mais ils ne surviennent que dans des usages "aux limites" et vous ne devriez pas tomber dedans en utilisation standard !

(26 Septembre 2020) Version 1.7.2

Nouveautés par rapport à la 1.7.1.1

Nouveau : lorsqu'on écrit un "petit" fichier (au plus 4096 octets) celui-ci est gardé en mémoire pendant tout le cycle d'écriture. Cela permet de gérer de façon plus correcte des fonctionnalités comme la "corbeille" de Nautilus/Nemo.
Nouveau : désormais le build est aussi fait sur le ppa pour ARM64. Cela permet par exemple à ceux qui essayent Ubuntu 64 bits sur leur Raspberry Pi 4 d'avoir directement un package 1fichierfs (pas besoin de compiler !).
Tests : cas de test rajouté dans la suite de tests de non régression pour vérifier la fonctionnalité.
Documentation : mise à jour de la documentation suite aux questions de math.hdr. Commande : man 1fichierfs

Mise à jour ?
La modification est mineure, surtout si vous n'utilisez pas la "corbeille".
Attention cependant, si vous utilisez la corbeille, et comme pour un disque local, les fichiers sont toujours sur votre stockage 1fichier.com et prennent toujours de l'espace. Si le fichier était dans le quota de "Cold", il continue à consommer son quota tant que vous ne l'avez pas "supprimé définitivement" de la corbeille.

Sur une installation Ubuntu par défaut, Nautilus créera un répertoire .Trash-1000 à la racine de votre stockage où il mettra les fichiers et informations de la corbeille. 1000 est le UiD de l'utilisateur par défaut (celui qui a installé), donc si vous utilisez 1fichierfs avec un autre utilisateur, vous aurez un autre nom correspondant au UID courant. Comme ce répertoire commence par un ".", vous ne le verrez pas avec Nautilus, sauf si vous affichez les fichiers cachés. Vous verrez néanmoins le répertoire sur votre stockage 1fichier.com.

Note la version packagée Focal (20.04) s'appelle en fait 1.7.2.1 car j'avais omis de changer la dépendance pour utiliser OpenSSL.

Raspberry Pi OS -ex Raspbian- (Raspbian Buster 32 bits): 1fichierfs_1.7.2~buster-1_armhf.deb

$ stat -c "%s %n" 1fichierfs_1.7.2~buster-1_armhf.deb; sha256sum 1fichierfs_1.7.2~buster-1_armhf.deb; md5sum 1fichierfs_1.7.2~buster-1_armhf.deb
80360 1fichierfs_1.7.2~buster-1_armhf.deb
6a3ea67d4c135048574f8b830d55ffb3972c61f18e2b92a91b953c0f179a12a9  1fichierfs_1.7.2~buster-1_armhf.deb
49f04d838d812950b8285f67ae0ae83d  1fichierfs_1.7.2~buster-1_armhf.deb

Todo list
- Initialisation de la partie écriture en mode "lazy".
L'intérêt est surtout pour ceux qui n'utilisent pas le driver pour écrire. Il n'y aura guère d'amélioration de performance car l'initialisation de l'écriture se fait déjà "en tâche de fond". Mais la partie écriture positionne deux choses qui lui sont indispensables : un répertoire de réception des fichiers (.upload_1fichierfs à la racine) et crée un "sous-compte" FTP pour l'upload. Avec l'initialisation active actuelle, il n'est pas possible de supprimer ces deux éléments, ou plutôt si on les supprime "à la main", c'est à dire sur l'interface web 1fichier.com, ils seront re-crées au prochain lancement de 1fichierfs.
Le mode "lazy", qui sera par défaut, ne fera l'initialisation de ces deux éléments que quand l'utilisateur écrit réellement un fichier sur son stockage au travers de 1fichierfs. Donc pour ceux qui n'utilisent jamais 1fichierfs pour stocker des fichiers en ligne, ils pourront supprimer ces deux éléments visibles (le répertoire et le sous-compte FTP) et 1fichierfs ne cherchera plus à les re-créer... sauf bien sûr si l'utilisateur change d'avis et utilise 1fichierfs en mode écriture !..
Inconvénient du mode "lazy" : la première écriture via 1fichierfs prendra plus de temps, puisqu'il faut faire cette initialisation globale qui n'a pas été faite au démarrage. Cet inconvénient sera cependant minimisé car 1fichierfs fonctionnera en mode "optimiste" en supposant que l'environnement est déjà tout Ok pour l'upload lorsque .upload_1fichierfs existe. L'overhead d'initialisation se déclenchera donc uniquement si par exemple la clé d'API a changé et donc que FTP retourne une erreur de mot de passe.
Pour diminuer cet inconvénient, l'option --zealous gardera le comportement actuel, et fera l'initialisation (en tâche de fond) dès le démarrage de 1fichierfs.

- Gestion des fichiers "perdus" à la reprise.
Si vous téléchargez une série de fichiers vers un nouveau répertoire, puis vous arrêtez 1fichierfs, le redémarrez rapidement et supprimez le répertoire qui est encore vide puisqu'il faut plus de 5min pour que les fichiers arrivent sur le stockage, à la prochaine reprise vous aurez des erreurs qui peuvent déclencher un bannissement en boucle car 1fichierfs va essayer de renommer des fichiers vers un répertoire qui n'existe plus (vous l'avez détruit !)

Pour sortir de cela, lorsque votre compte n'est plus banni, allez sur l'interface web, et supprimez tout ce qu'il y a dans .upload_1fichierfs

L'amélioration consistera donc à éviter autant que faire ce peut ce bannissement... surtout en boucle !..

Dans le cas où vous avez fait ce qui est décrit ci-dessus, 1ficherfs mettra les fichiers "perdus" dans un répertoire Lost sous .upload_1fichierfs dès qu'un répertoire cible est indiqué comme inexistant.
Le bannissement peut toujours se produire si vous avez fait la manipulation ci-dessus sur plusieurs répertoires différents (on n'a pas de moyen de savoir sans "risque de bannissement" si un répertoire est nôtre ou pas !) mais au moins il ne sera pas "en boucle" car au fur et à mesure les fichiers seront isolés dans le répertoire Lost.

Dans un cyle d'upload, cela ne peut pas se produire avec 1fichierfs uniquement, mais nécessite que vous manipuliez en parallèle 1fichierfs et l'interface web, et c'est donc que vous avez "désynchronisé" intentionnellement... on ne peut alors guère trouver de solution contre de tels agissements intentionnels !..

- Nouveau moteur de lecture.

Ça c'est un gros morceau...

Dernière modification par Zakhar (Le 26/09/2020, à 14:01)

math.hdr · Le 27/09/2020, à 22:02

Merci pour l'aide et les explications je repasserai par la si j'ai d'autres questions sur le sujet ...
Bonne continuation !

Zakhar · Le 27/09/2020, à 22:04

Pas de problème @math.hdr, et n'hésite pas à faire un rapport si tu vois des bugs...

En tout cas, depuis que j'ai fait réparer le "bug de free", ça marche nickel chez moi sur mes PC et Raspberry Pi en 32 et 64 bits. Curieusement la version 64 bits est plus lente alors que je m'attendais à ce que ça dépote en SSL... faudra que je regarde ça de plus près.

Zakhar · Le 07/11/2020, à 12:04

Bonjour les utilisateurs de 1fichierfs, je ne vous ai pas oubliés, le codage de la "lazy initialisation" avance.

Cependant je suis tombé sur deux problèmes techniques : ma box qui a lâché et qui tarde à être remplacée, et aussi un bug dans curl/libcurl (révélé précisément parce que ma box m'a lâché !..)

Le bug dans curl/libcurl, pour lequel j'ai fait un rapport. Oui vous savez, curl/libcurl, cet utilitaire/librairie qui est sans doute un des outils open source les plus utilisés au monde a bel et bien un bug qui nous affecte !
Il a été circonscrit à l'usage de TLSv1.3 dans l'upload FTP. La conséquence est qu'on peut perdre une partie aléatoire de la fin du fichier. Je ne m'en étais pas rendu compte jusque là parce que :

la plupart de mes "uploads" c'est pour de la sauvegarde de fichiers personnels. Il y a donc un chiffrement "à la source" (sur mon PC). Comme ce qui est stocké est du fichier déjà chiffré, mon espace "sauvegarde sur 1fichier" est utilisé en mode "non chiffré". En effet, faire du TLS sur un fichier déjà chiffré n'apporte rien d'intéressant, et fait juste perdre du temps et de l'énergie. Comme il s'agit alors d'upload "en clair" (puisque "déjà chiffré"), on n'est pas dans le cas du bug.
ma suite de test qui fait bien un upload de façon chiffrée n'avait jamais révélé le bug. Sans doute qu'avec la fibre c'était "trop rapide" pour déclencher le bug... mais en passant en FreeWifi bien moins rapide/fiable on voit clairement la chose ! En fait il faut que l'upload dure plus de 30 secondes pour voir le "bug", et le fichier standard de 128Mo met moins de 5 sec à uploader en fibre...

Après échange sur le ticket de bug curl (ci-dessus) vous aurez donc un "contournement temporaire" pour ce cas là : 1fichierfs va limiter à TLSv1.2 spécifiquement pour l'upload chiffré en FTP. En effet, le bug étant circonscrit à TLSv1.3 et ne se manifestant pas en TLSv1.2, cela corrige efficacement au prix d'une sécurité qui est un peu moins bonne. En effet, TLSv1.2 n'est pas encore déprécié ("deprecated") mais comme les menaces montent, TLSv1.3 a été mis en préparation, et on risque d'avoir un jour cette dépréciation de TLSv1.2.
Espérons que d'ici là le "bug curl" aura été corrigé et que j'aurai donc pu retirer le "contournement".

J'en ai aussi profité pour "nettoyer" un peu le script de test de non régression, notamment pour en sortir mes propres paramètres de test dans des fichiers externes de configuration.

Ah oui, aussi un sympathique pingouinaute qui utilise Archlinux m'a signalé (sur Gitlab) un bug de compilation avec GCC10 (sans incidence pour nous car Ubuntu est encore en GCC 9) que j'ai déjà corrigé, mais qui sera officiellement livré dans la version "lazy initialisation". Notre camarade "Arch" va voir s'il a le temps de fabriquer un AUR pour les utilisateurs de Archlinux (qui sont de toute façon plus que capable de faire tourner un "make" s'ils ont choisi Arch !..)

Le travail continue donc ! Restez à l'écoute.

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

Zakhar · Le 05/12/2020, à 13:51

(5 Décembre 2020) Version 1.8.0

Nouveautés par rapport à la 1.7.2

Contournement de bug libcurl : la librairie libcurl, utilisée par des milliers de logiciels, présente un bug pour l'upload FTPes (protocole utilisé par 1fichier.com) avec TLSv1.3. La conséquence de ce bug est qu'une partie de la fin du fichier uploadé est perdue. En attendant une éventuelle correction de l'équipe Curl, 1fichierfs limite à TLSV1.2 pour ce flux particulier d'upload. En TLSV1.2 le bug ne se produit pas. Cela n'affecte pas les anciennes versions (eg Ubuntu 16.04) où curl ne supportait pas encore TLSv1.3, ni évidemment quand vous uploadez vers un répertoire "en clair" déclaré par l'option --no-ssl.
Bug fix, rarissime "race condition" : il existait une "race condition" potentielle dans l'algorithme RCU utilisé pour nettoyer la mémoire en cours de vie du programme. Cette "race condition" que je n'ai jamais constatée ne peut se produire qu'avec au minimum 3 threads en parallèle dans certaines conditions particulières.
"Initialisation paresseuse" : désormais, l'environnement d'upload qui comprend le répertoire .upload.1fichierfs (à la racine de votre compte) ainsi qu'un compte ftp (que vous spécifiez ou calculé automatiquement) n'est initialisé que s'il y en a réellement besoin, c'est à dire si l'utilisateur écrit un fichier sur le montage.
Fonctionnalité : "nettoyage" en conséquence vous pouvez "nettoyer" cet environnement s'il ne vous est pas utile, et 1fichierfs ne le récréera pas systématiquement. Le "nettoyage" peut se faire depuis l'interface web de 1fichier.com ou simplement en supprimant le répertoire caché : .upload.1fichierfs. 1fichierfs n'autorisera cela que si le répertoire est non vide (normal !) et si vous n'avez pas déjà écrit sur le montage depuis qu'il est lancé. 1fichierfs supprimera alors aussi automatiquement le sous-compte ftp attaché. En ligne de commande vous pouvez "nettoyer" ainsi : rmdir 1fichier/.upload.1fichierfs (où 1fichier est votre répertoire de montage)
Comportement davantage standard précédemment, écrire sur le montage avant que l'initialisation du mode d'écriture en tâche de fond soit finie retournait une erreur. Ce n'est plus le cas, on peut écrire immédiatement, dès que le montage est visible. Simplement le démarrage réel de l'écriture attendra alors que l'initiation de l'environnement d'écriture soit terminé pour rendre éventuellement une erreur si cette initialisation échouait. Le comportement est donc désormais plus semblable à tout filesystem.
Meilleur partage de ressources pour l'écriture compte tenu de l'initialisation paresseuse, les sous-comptes FTP ne sont effacés que s'ils ne pointent pas sur le bon répertoire, ou si le mot de passe s'avère mauvais (vous avez changé la clé d'API). Dans ces conditions, si vous utilisez plusieurs instances de 1fichierfs sur des machines différentes de votre réseau local par exemple, il n'est plus nécessaire de spécifier des comptes FTP distincts pour chaque machine. Cependant, si plusieurs de ces machines utilisent l'écriture, il est recommandé de créer l'environnement d'écriture une fois pour toutes, en écrivant un fichier sur la première instance montée, puis monter les autres.
Optimisation en écriture désormais et à moins que vous n'ayez spécifié un mode sans écriture, l'option big_writes est passée automatiquement et toute diminution du max_write est ignorée. Cela améliore l'efficacité en écriture d'un facteur 2 (plus rapide ou consomme moins de CPU selon votre machine).
Amélioration : protections meilleure protection des fichiers spéciaux : statistiques, refresh et le répertoire d'upload. Le répertoire .upload.1fichierfs est en read-only (pour l'utilisateur). Les sous-répertoires de .upload.1fichierfs ne peuvent jamais être manipulés par l'utilisateur via 1fichierfs pour ne pas interférer avec le processus de "resume". Par contre les fichiers peuvent y être supprimés ou déplacés vers un autre répertoire s'ils sont plus anciens que le délai spécifié par --resume-delay (ou 15 minutes par défaut).
Tests : les variables spécifiques pour la suite de test sont désormais dans un fichier de configuration séparé..
Tests : cas de test rajouté dans la suite de tests de non régression pour vérifier les nouvelles fonctionnalité.
Documentation : mise à jour de la documentation pour la fonctionnalité "initialisation paresseuse". Commande : man 1fichierfs

Mise à jour : conseillée
Il s'agit d'une version majeure, et elle corrige une "race condition" (sans doute rarissime) pouvant provoquer un crash, mais surtout contourne un bug de libcurl si vous utilisez 1fichierfs pour uploader des fichiers qui peut corrompre vos sauvegardes faites via 1fichierfs.

Quelques précisions "techniques".
A part si vous montez autre chose que la racine du compte, cas où 1fichierfs doit parcourir l'arborescence distante et donc fait plusieurs appels, le démarrage de 1fichierfs se fait toujours après un seul appel serveur (listage de la racine du compte) et prend donc une fraction de seconde (en général en dessous de 0,1 sec !). Si vous n'avez pas/plus besoin d'écrire/sauvegarder via 1fichierfs et que vous avez nettoyé l'environnement d'écriture, il y a désormais zéro appel serveur en tâche de fond au démarrage. Bien sûr, vous pouvez changer d'avis à tout moment et décider d'écrire à nouveau, auquel cas l'initialisation prendra un tout petit peu de temps pour le premier fichier que vous écrivez. Si l'environnement d'écriture est initialisé, le démarrage est identiquement rapide, le process en tâche de fond ne fait plus comme précédemment suppression/création du compte ftp mais se contente d'une lecture et vérifie qu'il existe. Si le mot de passe (c'est à dire la clé d'API) n'a pas changé, cela suffit, et c'est dans l'immense majorité des cas moins de ressources consommées client et serveur, même si ces phases étaient invisibles car en tâche de fond. Et donc si l'environnement d'écriture reste initialisé, il est toujours récupéré au démarrage en tâche de fond ce qui permet de ne même pas retarder la première écriture.

Raspberry Pi OS -ex Raspbian- (Raspbian Buster 32 bits): 1fichierfs_1.8.0~buster-1_armhf.deb

$ stat -c "%s %n" 1fichierfs_1.8.0~buster-1_armhf.deb; sha256sum 1fichierfs_1.8.0~buster-1_armhf.deb; md5sum 1fichierfs_1.8.0~buster-1_armhf.deb 
82828 1fichierfs_1.8.0~buster-1_armhf.deb
c9029ee411046903a8cc4b8362852c7d18a209e5902e6dd0b78ac6166a0390b5  1fichierfs_1.8.0~buster-1_armhf.deb
edd3240843c7e7ee57a18f68a2ccd2f5  1fichierfs_1.8.0~buster-1_armhf.deb

Dernière modification par Zakhar (Le 05/12/2020, à 14:27)

math.hdr · Le 07/12/2020, à 18:19

Salut, depuis le temps j'ai réfléchi à un projet en me servant de 1fichierfs ...
Je vais installer un serveur FTPS (ubuntu) pour me permettre de visionner mes vidéos sur ma smart tv, ou sur téléphone / pc de ma famille en connectant mon serveur a Kodi Media Player (qui permet la connexion à un serveur FTPS ).
Le principe sera alors de monter 1fichierfs dans un répertoire que je vais partager avec mon serveur FTPS. Si j'ai bien compris je ne peux télécharger ( et donc diffuser avec mon serveur FTPS) que quatre vidéos en même temps sur le même pc avant qu'il y ai des bugs/instabilités ?

D'où vient cette limitation ?
Y aurais t'il un moyen d'augmenter le nombre de téléchargement simultané ?
Autre question qui n'a rien à voir, une idée de la puissance nécessaire au serveur pour diffuser les flux en simultané (en fonction du nombre de flux possible du côté de 1fichierfs) s' ils sont en 1080p ?

Merci !

Zakhar · Le 07/12/2020, à 19:51

Bonjour,

Oui, le principe fonctionnera si tes équipements smart tv, téléphone / pc, sont capables de "streamer" sur du ftps !..

Tu peux aussi mettre des outils différents selon ce que tes équipements savent faire. Par exemple la Freebox sait faire du DLNA, et donc j'ai déjà fonctionné ainsi :

[1fichier.com] ==(https)==>[Ubuntu + Driver 1fichierfs + minidlna (sur le répertoire ~/1fichier)] ==(DLNA)==> [Freebox Player] <>[TV]

Même en rajoutant la couche chiffrement (enfs) ça marche aussi. Les montages "fuse" sont "stackable".

En pratique il serait étonnant que tu arrives à la limite de 4 flux simultannés... du moins avant de saturer autre chose !

Tout dépend en fait de ton serveur, et de ta liaison web.
En ADSL, même un flux 1080p tu vas être à a peine... donc faut penser à la fibre.

Après si ton serveur est un Raspberry Pi, l'autre saturation peut venir du CPU et du travail que tu lui demandes en lisant en https et en re chiffrant pour le ftps...

Cependant la "puissance" demandée n'a rien à voir avec un Plex qui ferait de décodage/encodage à la volée. Là il s'agit juste de flux réseau, et le plus gros du CPU est consommé par le TLS (chiffrement et déchiffrement).

La limitation à 4 flux en lecture est une limite "raisonnable" codée "semi-en-dur", c'est là :

#define MAX_READERS 4

Elle est aussi là pour éviter que les usages déraisonnables comme "revendre" du flux vidéo/audio à d'autres en stockant tout sur 1fichier...

En "théorie" (si j'ai pas merdé ailleurs) il suffit de changer le "define" pour obtenir plus de "readers".
L'autre option qui demande un peu plus de boulot est de le rendre paramétrable par une option au lancement.

Fais tes tests, et dis-moi si c'est vraiment utile de monter cette valeur. Cela a des effets adverses d'avoir beaucoup de "readers" car à chaque requête de lecture on cherche à quel "reader" on va l'affecter... s'il y a top de "readers" il faut potentiellement revoir l'algorithme pour faire autrement qu'une recherche séquentielle.

Si tu constates des ralentissements, je te conseille de lancer le driver avec les statistiques et d'observer ce qu'il se passe.

Commande :

1fichierfs ~/1fichier --api-key=@macleapi.txt --stat-file='.stats'

Ensuite dans un terminal tu tapes :

watch -n3 ~/1fichier/.stats

Toutes les 3,0s: cat /home/zakhar/1fichier/.stats                                                                                                                         zakhar-HTPC: Mon Dec  7 19:44:34 2020

Uptime: 05:29:51

Readers:
     Down. N.Req  Avg Time  Max Time   Ref  Qu N.Err Speed Av.Sp
[01]  552M  4435    0.0031    0.9420 (   8)  0     0 5094K 3647K
[02]  248M  2017    0.0037    0.8125 (   6)  0     0  384K 1946K
[03]  524M  4219    0.0041    0.3290 (   7)  0     0 3584K 3487K
[04]  267M  2155    0.0058    0.2289 (   5)  0     0 4659K 3463K
----------------------------------------------------------------
Tot. 1592M 12826    0.0040    0.9420         0     0 13.3M 9651K

API:
                        N.Req  Avg Time  Max Time Retry N.Err
folder/ls.cgi         :    25    0.3950    6.0567     0     0
download/get_token.cgi:    11    0.1305    0.3321     0     0
user/info.cgi         :     2    0.0447    0.0457     0     0
ftp/users/ls.cgi      :     1    0.0498    0.0498     0     0
--------------------------------------------------------------
Total                 :    39    0.2936    6.0567     0     0

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

             Number Memory
Allocations:   6798  17.6M
Frees      :   6529  17.3M
Difference :    269   356K
Contentions:      0      0

Live streams: |Write| 0    (Read) 9
  Ref   Size  Left Lnk Er N.Loc N.Stm Path
(   1) 16.5G 26:29   0        1     1 /.crypt/jZvYsH3lERz3iUTa4lwi6Ttu/2NAbnKthuLyfxWtgDNb8Vp19fCWi0d6sUQ5bh6exb6v-U-
(   2) 18.9G 26:29   0        1     1 /.crypt/jZvYsH3lERz3iUTa4lwi6Ttu/L4LGHzu6npKqKKF9odqLJh0wdb7WoRijwmfcKJvatDk7G-
(   3) 22.0G 26:29   0        1     1 /.crypt/baJz,T4zl445GgFj5pXVq,fE/S8TJJ7pHe2mI2KcGbZJ42MAAu6uRgglZ66Bxl9H3uAfCo0
(   4) 16.1G 26:29   0        1     1 /.crypt/jZvYsH3lERz3iUTa4lwi6Ttu/RlChyw8-weMamDyPrXjvodsrGbC3h,c3Md36bHMiE8MjD,
(   5) 32.0G 28:04   2        1    10 /.crypt/-FzSkQU-2euzGhZsYT7finNL/evg6Yva2rCJOBeoml,mcdC70VZZpfmD74MRcRAsQjnwZ-03Q9iOWS5RyB,cN6zcHs43
(   6) 28.8G 28:47   2        1     9 /.crypt/-FzSkQU-2euzGhZsYT7finNL/B-M2btOAcTlbI798QYr2WNPjwtMYdKnZg4wzEgyZkonsr7wl-0tR6,VouhAyPxjEFtD
(   7) 23.3G 27:16   2        1    14 /.crypt/-FzSkQU-2euzGhZsYT7finNL/voRYuOthg6yOpl3AZMUsRoXmm1URpN8SBL8D55fWYoAy8aPCMwosJe5OHeiRxASHKhiO9FFUG,xoXeZStEuIuyiB
(   8) 32.5G 27:28   2        1    12 /.crypt/-FzSkQU-2euzGhZsYT7finNL/4edkyxOgVXguVjdxjHV7mmAK9ewkgUeEyfZTzK0DZAOMWNIIJZ3QCdZPKMlAP,UMlZC
(   9)    49 26:28   0        1     1 /.crypt/8jAmcUwiS,EFy-YtyJnRbnmb

Comme tu le vois, ci-dessus, test avec du flux équivalent à du Full-BluRay 1080 stocké sur la partie chiffrée de mon compte. Cela passe donc en plus par la couche encfs, d'où les noms de fichier bizarre ci-dessus.

Ca pompe 13Mo de bande passante, et les 4 readers bossent chacun pour un fichier différent. Le test étant sur mon PC de bureau, il ne bouge pas d'une oreille pour faire ça, même en rajoutant encfs au milieu. Le Raspberry serait sans doute à la ramasse dans la même situation !..

Tu peux compter en bande passante autour de 5Mo/s (40Mbps) pour du full blu-ray, et plutôt 2Mo/s (16Mpbs) pour du 1080p "standard" (fichiers autour de 10Go) et la moitié en "webdl".

1fichier.com a également une limite (non publique) en nombre de flux par adresse IP. Elle est largement plus élevé que 4 cependant.

Si dans les statistiques ci-dessus, au dessous des 4 lignes de "reader" tu vois une ligne "solo", c'est que ça commence à "saturer", et là ça va ralentir !..
... mais hormis "revente de flux" que j'aimerais autant ne pas favoriser, tu dois avoir une famille très nombreuse pour que chacun décide de voir un flux différent stocké sur ton 1fichier pile au même moment... et saturer les 4 flux !..

Dernière modification par Zakhar (Le 07/12/2020, à 20:04)

math.hdr · Le 12/12/2020, à 17:38

Bonjour,
J'ai bien compris quelle ligne changer pour augmenter le nombre de Readers mais je n'ai pas compris quel fichier modifier ou comment y procéder...
Je n'avais pas vu les stats, plutôt pratique !
Mon projet a pour but de coupler la puissance de 1fichier.com avec la flexibilité d'un serveur ftps, mais je vous rassure uniquement dans un cadre privé (pour le défi technique aussi ...)
Si ça vous intéresse je pourrais vous faire un rapport (des éventuels bugs) et du nombre de connexions simultanés que j'arrive à effectuer avec la fibre et un serveur I3 / 8go de ram / ssd...

Zakhar · Le 12/12/2020, à 18:27

En fait si tu fais du "téléchargement", 1fichierfs perd une partie de son intérêt puisque un gros plus, concernant les médias (vidéo, musique) est de pouvoir précisément les écouter/regarder sans les télécharger. Ce qu'on appelle autrement du "streaming" !

Par ailleurs, à part si tu fais des tests de charge, 1fichier.com fournit en général un excellent service et donc télécharger un fichier disons de 10Go sur une ligne en Gigabit (fibre Free "de base" !..) ça va mettre moins d'une minute et 30 secondes !..
Le "parallélisme" va donc être fort limité, et les 4 "readers" suffiront en usage normal.

Aussi, lorsque je récupère mes sauvegardes, je parviens bien à saturer ma fibre avec un seul téléchargement via 1fichierfs. Donc en faire plusieurs en parallèle ne fait gagner aucun temps, puisque ce qui limite est la vitesse de la fibre qui est déjà saturée avec 1 téléchargement !.. C'est le fameux truc des "accélérateurs de téléchargement" tu sais, dont le principe est de couper le fichier en morceaux et ouvrir plusieurs flux sur le même fichier. En l'occurrence chez moi, ça ne sert à rien du tout, donc télécharger "plein de fichiers en parallèle" ne te fera gagner aucun temps par rapport à les télécharger "en série".

Bien sûr on peut démontrer des usages "de test" où on arrive à saturer les 4 readers, je le fais pour tester mon programme.
Il suffit d'avoir plus de 4 gros fichiers. Par exemple j'ai plus de 4 gros fichiers qui commencent par la lettre T sur la racine de mon stockage, en faisant :

{ find ~/1fichier -maxdepth 1 -type f -name 'T*' | xargs -P5 -n1 cat ;} >/dev/null

Bah ça sature, puisque on demande explicitement de faire 5 'cat' en parallèle.
J'avoue qu'à part pour tester que les statistiques fonctionnent et qu'on arrive bien à saturer les "readers", ce genre de truc ne m'est jamais arrivé dans mes usages normaux !

Voici le résultat du test, on a bien des "solo" puisqu'on a explicitement lancé 5 téléchargements en parallèle, et tu vois la vitesse moyenne des "solo" par rapport aux readers !:

Readers:
     Down. N.Req  Avg Time  Max Time   Ref  Qu N.Err Speed Av.Sp
[01]  604M  4838    0.0104    0.9520  idle   0     0     0 20.8M
[02]  884M  7081    0.0069    1.0544  idle   0     0     0 31.5M
[03]  516M  4136    0.0124    0.6171  idle   0     0     0 18.4M
[04]  809M  6477    0.0079    0.7276  idle   0     0     0 26.9M
solo 9856K    77    0.6878    1.6816               0        186K
----------------------------------------------------------------
Tot. 2824M 22609    0.0113    1.6816         0     0     0 88.2M

Ah, et oui, les stats c'est joli et souvent inutile, donc rigoureusement indispensable bien sûr !
Non, en vrai ça sert bien quand tu as un comportement que tu penses anormal pour vérifier ce qu'il se passe. Donc je recommande l'option, même si elle ralentit un chouia c'est invisible sur une machine "normale" et ça peut servir.

Mais bon, tu as peut-être des usages différents.

Si au contraire tu veux faire du "streaming", pour que toute la famille puisse regarder des vidéos sans les télécharger préalablement (encore que 90 secondes c'est pas la mort !), ftps n'est sans doute pas la bonne solution.

Je te conseille plutôt DLNA (appelé parfois UPnP AV) sur le serveur, et côté clients soit un VLC, soit un Kodi.
Pour la "box player", celle de Free sait aussi faire DLNA, donc ça permet d'afficher sur la télé... je ne sais pas pour les autres "box players" des autres FAI.
En ftps par exemple, sur la Freebox Player, tu ne pourrais pas regarder un film stocké sur 1fichier.com via ton i3 et 1fichierfs. En effet, "streamer" sur du ftps, ce n'est pas un truc que la box sait faire (et à mon avis aucune ne le fait). Tandis que DLNA, c'est fait pour ça.

Là, en stream, tu peux potentiellement "saturer" si plus de 4 flux jouent en même temps... c'est un cas vraisemblable ?

Par contre il m'arrive souvent de faire ce genre de "saturation" sur la Freebox :
Courbe de débit

Le "pic" vert correspond au test avec les 5 lectures, mais pas besoin de ça pour saturer !

Le truc sur la droite, c'est un unrar de fichiers sur mon 1fichier vers un répertoire sur 1fichier avec en parallèle une copie de la zone "en clair" vers la zone chiffrée.
Donc là j'ai utilisé en parallèle 2 readers et 2 writers pendant quelques minutes.
Ce qui sature dans ce cas c'est l'upload. Il faut 2 uploads en parallèle parce que les FTP de 1fichier.com ne sont pas aussi rapides que le téléchargement.
Mais avec deux copies (upload) en parallèle j'arrive même à monter au delà du débit supposé "max" de la Freebox. Quelques pointes à plus de 90Mo/s alors que le maximum théorique est 87,5Mo/s !

Dernière modification par Zakhar (Le 12/12/2020, à 19:18)

Zakhar · Le 20/12/2020, à 22:12

(20 Décembre 2020) Version 1.8.1

Nouveautés par rapport à la 1.8.0

Bug mineur : la racine du montage affiche désormais la bonne date (celle de modification du répertoire de montage) au lieu du 1/1/1970 !..
Protection de bannissement au redémarrage : si vous avez créé un répertoire, envoyé des fichiers, coupé le driver tout de suite... puis change d'avis et supprimé le répertoire cible via l'interface web, le redémarrage provoquait un bannissement en boucle en tentant de renommer vers le répertoire que vous aviez intentionnellement supprimé. Désormais le répertoire détruit est "blacklisté", et les fichiers sont mis dans /.upload.1fichierfs.
Changement de valeur par défaut à l'option --resume-delay celle-ci vaut désormais 27 heures, ce qui couvre les 24h de rétention FTP (si pas en "automatique") et le cas d'un fichier de 300Go (max supporté par 1fichier.com) qui serait déclenché juste avant les 24h. Cette valeur s'applique aux répertoires orphelins et à la protection du répertoire d'upload. Les uploads complets (fichier et répertoires) sont traités s'ils datent de plus de 5 minutes (non paramétré).

Mise à jour : version mineure
Surtout si vous n'utilisez pas le driver pour écrire, la MàJ n'est pas indispensable !..

Raspberry Pi OS -ex Raspbian- (Raspbian Buster 32 bits): 1fichierfs_1.8.1~buster-1_armhf.deb

$ stat -c "%s %n" 1fichierfs_1.8.1~buster-1_armhf.deb; sha256sum 1fichierfs_1.8.1~buster-1_armhf.deb; md5sum 1fichierfs_1.8.1~buster-1_armhf.deb 
83204 1fichierfs_1.8.1~buster-1_armhf.deb
1fbca5d3b93476df8b2a757129952dfbea2ce2059f41d70516e5d2a4a80824a6  1fichierfs_1.8.1~buster-1_armhf.deb
ad4e68ae771dc8d03f3c63b624606677  1fichierfs_1.8.1~buster-1_armhf.deb

Dernière modification par Zakhar (Le 21/12/2020, à 07:50)

Zakhar · Le 25/12/2020, à 23:16

Direction future:

Bonjour, les utilisateurs de 1fichierfs, et bonne fêtes de fin d'année à toutes et tous !

Le futur est un nouveau "moteur de lecture" plus simple et plus performant. Il sera basé sur une partie plus basique de curl: curl_easy_recv(), qui fait à peine plus que préparer les "sockets" (mais c'est déjà beaucoup) et donner la main à l'application.

Cela va faire plaisir à math.hdr (encore que je doute que ça en ait gêné beaucoup depuis la création de 1fichierfs !), mais il n'y aura plus un nombre fixe de "readers" (4), mais un nombre de "streams" maximum par fichier ouvert.

La lecture se fera directement dans le thread de fuse, sans nécessiter la double bascule de contexte due aux "readers". Les seuls changements de contexte, entre threads de fuse, seront dû à des requêtes d'un même "stream" arrivant en désordre (ce qui survient parfois : les voies impénétrables de l'asynchronisme sont ainsi !).

Ce tout nouveau moteur de lecture étant une refonte profonde de cette partie là qui est au cœur du programme (et la partie la plus ancienne), va prendre un peu de temps.

Ce n'est pas bien grave, parce que ça marche pas mal en l'état et ça fait pas loin de tout ce qu'on peut faire décemment avec l'API actuelle de 1fichier.

Sans doute donc... à l'année prochaine !

Jarodd · Le 10/01/2021, à 15:46

Bonjour !

Je suis intéressé par les services d'1Fichier.com, j'ai attentivement lu les CGU, mais je les trouve très légères en terme de définition.
Je profite donc ce ce sujet, pour poser quelques questions, si je m'abonne je testerai aussi le script ! J'ai juste quelques messages mais pas les 11 pages, je m'excuse si la question elle est déjà répondue.

Je cite les CGU :

1.
Définitions
Cold Storage : tout contenu n’ayant aucun accès
depuis plus de 60 jours francs.
Hot Storage : tout contenu qui n’entre pas dans
la définition du Cold Storage.

a)
Offre Premium
L’offre Premium inclut un accès non dégradé aux
services de stockage, incluant toutes les
fonctionnalités disponibles sur celui-ci ainsi que
toutes les meilleures interconnexions réseau à
disposition de DSTORAGE. L’offre inclut par
défaut un espace illimité de Hot Storage, 2To de
Cold Storage, 100Go par mois de crédits CDN.
Des capacités de Cold Storage supplémentaires
peuvent être commandées au travers de
l’interface de gestion du compte. Tout impayé
peut entrainer une perte de données
irrémédiable

Imaginons que j'ai plusieurs To de vidéos à stocker. Pas du contenu illégal, plutôt des enregistrements sur la bos qu'on peut récupérer, et conserver. Je ne souhaite pas le partager, mais si mon disque dur lâche, je perds tout (j'ai déjà une sauvegarde en local, je cherche une sauvegarde à distante désormais).

Avec les deux définitions, je n'arrive pas à savoir dans quelle catégorie entrent mes vidéos. 60 jours après l'upload, personne n'y aura accédé (à part moi si je souhaite les mettre sur un nouveau disque dur). Vont-elles donc basculer sur du cold storage ? Donc à l'upload je pense disposer de l'espace illimité, et au bout de 2 mis, en serai-je réduit à 2 To de stockage, et donc à repasser à la caisse pour avoir plus de To disponibles ? Vous comprenez que si c'est le cas, l'offre est bien moins intéressante que si mes fichiers peuvent être stockés en "illimité" (notion vague juridiquement).

Donc je ne sais pas que faire. Le support n'a pas l'air de vouloir répondre, ce qui est généralement mauvais signe pour moi. Je m'adresse donc aux personnes qui utilisent déjà ce service, et cette offre Premium

Merci d'avance pour votre aide à y voir plus clair !

Dernière modification par Jarodd (Le 10/01/2021, à 15:47)

Zakhar · Le 10/01/2021, à 16:35

Bonjour Jarodd,

Oui, tu as bien compris le fonctionnement.
S'il s'agit de fichiers "personnels" (non partagés, et sans doute non "déduplicables") ils passent dans le "Cold" au bout de 60 jours.
Autrement dit, si ton usage est des fichiers personnels, tu peux compter tout de suite 100% de "Cold" !..

Et désolé, il n'y a pas "miracle" un stockage "personnel" à distance a un coût, et à ce jour c'est 1fichier qui a les prix les plus bas du marché... sans doute aussi précisément parce qu'il y a pas mal de "partage", ce qui était le modèle initial de tels prestataires.
D'ailleurs, le "concurrent" Uptobox interdit purement et simplement le "Cold", et n'autorise que le "partage". Au moins c'est clair sur l'usage !..

CGU de Uptobox a écrit :

Règlementation du Fair use
Dans le but de maintenir nos prix compétitifs et fournir une grande qualité de service, Nous nous réservons le droit de limiter tout compte faisant preuve d'abus de notre service :
(...)
- Réaliser du "cold storage" (vos fichiers ne sont presque jamais téléchargés) n'est pas autorisé. Le "Hot storage" est illimité.

Source : https://uptobox.com/tos

Regarde le post #1 où j'ai fait un petit comparatif pour 2To de stockage.

En "prix catalogue", 1fichier est à 22€/an... sans parler des "promotions fréquentes". Il y en a eu une récemment avec -30% sur Groupon.
Le numéro 2 en prix est Kdrive à presque le triple autour de 60€/an.
Les poids lourds comme Google sont eux à 5 fois le prix autour de 100€/an.

Dans le comparatif, je n'ai pas non plus compté les coûts de transfert. Pour 1fichier, c'est "illimité". Kdrive par exemple a des limites. Je ne sais pas si elles sont génantes ou pas !..
En tout cas il m'est arrivé certains week-end de grande activité sur mes "sauvegardes" de dépasser le Téra transféré... 1fichier ne m'a jamais rien dit...
Bien sûr d'un côté il y a des jours où je transfère peu ou pas de données aussi, globalement ça fait doit faire une moyenne raisonnable.

Donc si c'est une question de prix, tu peux toujours gérer des sauvegardes à distance "personnelles" en les hébergeant ailleurs (familles, amis) sur des disques "perso".
Par exemple, un Baracuda 8To, ça coûte 170€ (recherche vite fait sur Amazon), ce qui fait, au prix de 1fichier, 2 ans de stockage.

Par contre je compte là juste le prix brut du disque, sans rajouter la redondance (ton disque de sauvegarde peut casser aussi !), le courant, la machine, les programmes, le temps pour s'occuper de tout ça etc...
Donc si tu redondes ton Baracuda, plus le prix d'un petit NAS de base à deux baies, tu arriveras vite à 6 ou 7 ans d'abonnement 1fichier pour amortir le prix d'un truc un peu "sérieux"... délai au bout duquel ton matériel sera obsolète !..
J'ai fait les calculs avec mon propre NAS...

La bon "équilibre" dépendra donc de l'usage. Avec 1fichier, tu as tes sauvegardes distantes toujours disponibles 24/24 à la vitesse de ta connexion (j'arrive à 1Gbps quasiment en permanence en lecture).
Mais pour des "sauvegardes dormantes", c'est sans doute de la confiture aux cochons d'avoir une telle disponibilité en ligne.
Pour ce genre de besoin, il y a des services spécialisés, mais plutôt "entreprises" comme Amazon Glacier. Mais quand tu regardes les prix (hébergé en France): 0,0045USD /Go par mois... ça fait finalement du 110USD par an pour 2To, soit le niveau de Google Drive, et en plus tu vas payer les extractions, et les transferts...
Source : https://aws.amazon.com/fr/glacier/pricing/

Donc à toi de voir !..

Ah oui, aussi la différence entre 1fichier et Kdrive (ou Google Drive), c'est que 1fichier c'est du service quasi "brut" de stockage. Le seul "logiciel" fourni officiellement est un site web.
Les autres fournissent des "drivers" pour accéder plus facilement aux données.

... mais bon, maintenant sur Linux tu as 1fichierfs, donc au moins sur cet O.S., l'offre est à niveau.

Dernière modification par Zakhar (Le 10/01/2021, à 16:38)

Jarodd · Le 10/01/2021, à 18:13

Merci Zalhar : tu confirmes ce que j'avais compris. Donc l'offre 1fichier n'est pas pour moi. C'est vrai qu'il y a d'autres offres, mais je veux éviter les GAFAM. Je suis en train d'essayer pcloud. J'ai testé Kdrive, je ne suis pas convaincu (l'interface est mal foutue, les débits très lents). Il me reste Mega, mais c'est hébergé dans un des Five Eyes, donc ça me rebute un peu (même s'ils assurent ne pas avoir la clé de chiffrement). Et je trouve qu'il est assez cher (il me faut plusieurs To, d'où la recherche d'illimité, ou presque).

Par contre je me demande comment, avec le système 1fichier, on peut être certain que les fichiers soient tout le temps partagés (enfin, au mois une fois tous les 60 jours). A part pour du téléchargement trucs illégaux, je ne vois pas comment on peut faire ! Pour du légal, une fois que toute la famille a pris les fichiers, le fichier ne sera plus partagé un jour où l'autre, donc il sera en cold storage. Donc le seul intérêt de 1fichier est ce "partage permanent", et je ne vois pas d'autres cas que du DDL. A moins de cliquer soi même sur ses propres liens

Zakhar · Le 10/01/2021, à 19:24

Oui, ou fichiers partagés en entreprise.

Après là où 1fichier fait son affaire, c'est que si tu mets un fichier partagé sur ton compte, ce qui est compris comme une "copie", mais en réalité n'est qu'un lien vers un contenu, ce fichier que tu as "copié" devient "Cold" au bout de 60 jours si tu ne le re-partages pas toi-même, même si la source elle-même reste un truc très partagé.

Du coup, ça fait un "facteur de déduplication" intéressant qui leur permet de se démarquer en prix.

Il n'y a pas de mystère !

En regardant le "prix public" des grands acteurs, tu peux compter que la sauvegarde d'un Giga te coûte 5 centimes par an. Donc si tu as plusieurs Tera, tu vas vite arriver à plusieurs centaines d'euro par an que tu fasses toi-même ou que tu utilises un prestataire.

Pour le stockage privé, à partir de Linux je recommande encfs (avec le fichier xml chez toi).
Ainsi ce qui est stocké n'est qu'une suite d'octet sans signification, idem pour les noms de répertoire et de fichiers.
Du coup peu importe 5 eyes ou pas !..

Inconvénient, si tu veux lire des fichiers à partir d'un autre système, c'est mal barré !..

encfs est tout à fait "stackable" par dessus 1fichierfs, j'ai fait en sorte que ça fonctionne aussi pour l'écriture malgré la façon particulière de fonctionner de encfs dans ce mode.
Par contre tu ne peux pas renommer/déplacer des fichiers sous l'arborescence gérée par encfs car cela écrit dans l'entête du fichier, et l'écriture aléatoire n'est en gros prévue par aucun fournisseur de stockage (sauf les rares qui utilisent WebDAV).

Dernière modification par Zakhar (Le 10/01/2021, à 19:25)

Zakhar · Le 10/01/2021, à 19:59

Jarodd a écrit :

Il me reste Mega, mais c'est hébergé dans un des Five Eyes, donc ça me rebute un peu (même s'ils assurent ne pas avoir la clé de chiffrement). Et je trouve qu'il est assez cher (il me faut plusieurs To, d'où la recherche d'illimité, ou presque).

Oui, pour comparer aux 2To de mon benchmark, Mega est à 120€/an
Après selon le volume, ça peut être intéressant parce que l'offre pour 8To n'est pas le quadruple, mais juste le double à 240€/an

Cela dit, avec 1fichier tu serais à 94€/an pour 8To... donc ça reste favorable.
Sur 1fichier tu ne payes que les Tera "en débordement". C'est ce qu'ils appellent "overquota". Quand tu dépasses les 2To, ils envoient un mail t'invitant soit à supprimer des fichiers et revenir dans le quota, soit à acheter 1To supplémentaire.
Donc le prix grimpe progressivement par Tera consommé, tu ne payes pas d'avance un "paquet de Tera"... tu n'as d'ailleurs même pas le choix de faire ainsi si tu le voulais.

Dis-nous le résultat quand tu auras comparé !

Après un truc que le driver 1fichierfs ne fait pas, c'est "agréger" des comptes 1fichier... En effet, le prix d'un abonnement est un peu moins cher que les 2To supplémentaires. Donc en réalité, si tu veux par exemple 8To, tu pourrais prendre 4 abonnement pour 88€, moins cher que les 94€ théorique avec abonnement + supplément.

Dernière modification par Zakhar (Le 10/01/2021, à 20:02)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#251 Le 21/05/2020, à 16:09

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

#252 Le 18/09/2020, à 20:04

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

#253 Le 18/09/2020, à 20:33

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

#254 Le 19/09/2020, à 10:45

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

#255 Le 19/09/2020, à 11:18

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

#256 Le 19/09/2020, à 11:42

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

#257 Le 19/09/2020, à 12:58

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

#258 Le 20/09/2020, à 17:26

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

#259 Le 20/09/2020, à 17:53

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

#260 Le 26/09/2020, à 12:26

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

#261 Le 27/09/2020, à 22:02

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

#262 Le 27/09/2020, à 22:04

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

#263 Le 07/11/2020, à 12:04

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

#264 Le 05/12/2020, à 13:51

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

#265 Le 07/12/2020, à 18:19

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

#266 Le 07/12/2020, à 19:51

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

#267 Le 12/12/2020, à 17:38

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

#268 Le 12/12/2020, à 18:27

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

#269 Le 20/12/2020, à 22:12

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

#270 Le 25/12/2020, à 23:16

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

#271 Le 10/01/2021, à 15:46

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

#272 Le 10/01/2021, à 16:35

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

#273 Le 10/01/2021, à 18:13

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

#274 Le 10/01/2021, à 19:24

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

#275 Le 10/01/2021, à 19:59

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

Pied de page des forums