Contenu | Rechercher | Menus

Annonce

DVD, clés USB et t-shirts Ubuntu-fr disponibles sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

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

Zakhar

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

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


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

En ligne

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

math.hdr

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

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é !

Hors ligne

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

Zakhar

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

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)


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

En ligne

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

math.hdr

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

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)

Hors ligne

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

Zakhar

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

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)


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

En ligne

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

math.hdr

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

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 !

Hors ligne

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

Zakhar

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

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)


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

En ligne

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

math.hdr

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

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

Hors ligne

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

Zakhar

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

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 ! big_smile

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


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

En ligne

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

Zakhar

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

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 !.. tongue

- Nouveau moteur de lecture.

Ça c'est un gros morceau...

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


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

En ligne

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

math.hdr

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

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

Hors ligne

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

Zakhar

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

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.


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

En ligne

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

Zakhar

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

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)


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

En ligne

#264 Aujourd'hui à 13:51

Zakhar

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

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


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

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

En ligne