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

sefaaras · Le 28/01/2022, à 11:30

Zakhar a écrit :

Et à votre écoute pour le "problème important" !..

Comment puis-je contacter par courrier ou comment puis-je être plus rapide.

Zakhar · Le 28/01/2022, à 13:44

sefaaras a écrit :

Comment puis-je contacter par courrier ou comment puis-je être plus rapide.

Tu peux m'envoyer un message privé via ce forum.

Quant à la rapidité de correction... c'est de l'OpenSource, et je fais ça sur mon peu de temps libre. Pour aller plus vite le source est sur GitLab, tu peux proposer des corrections directement !..
Aussi avant de corriger un bug, encore faut-il l'avoir identifié.

Ton plantage est bizarre, en plus 11 contentions pour si peu et déjà du "solo" alors que tu as à peine démarré !..

Il faudrait à l'idéal faire tourner avec "debug" mais pour ça il faut partir du source car le package n'a pas le code de debug, ou sinon que tu me décrives ton usage (en MP si tu veux) que je tâche de reproduire le bug.

Tous les "file lockers" marchent sur le même principe. Les "liens" que tu vois et qui circulent / sont partagés ne sont pas directement utilisés pour télécharger. Quand tu utilises le lien, le serveur te donne un autre lien "temporaire" qui permet réellement de télécharger. Cette manœuvre est invisible de l'utilisateur (redirection en général). Ce lien "temporaire" a une durée de validité donc, chez 1fichier ça varie entre 30 et 50 minutes (dans le cas général), chez Uptobox c'est plusieurs heures.
Avec l'API, tu ne peux pas avoir plus de 500 "liens temporaires" valides à un instant T. C'est à dire tu as droit à 500 "slots". Au delà tu as le message d'erreur que tu affiches.
L’identification réseau contourne la limitation, mais n'est utilisée que quand on a précisément ce blocage car c'est sensiblement plus lent.

Zakhar · Le 28/01/2022, à 18:50

J'observe aussi 3 erreurs sur ton listage, étrange, des fichiers issus d'un "partage" ?

Je vois aussi des fichiers avec une 100aine de streams. Ca sent les fichiers ISO, et il est vrai que si tu ouvres "au gestionnaire de fichier" (nautilus sur Ubuntu standard Gnome) un répertoire contenant des ISO, nautilus va essayer d'ouvrir tous les ISO un par un. Le temps de réaction n'est pas fameux parce que ce n'est pas du séquentiel, mais en principe ça ne plante pas... en tout cas pas chez moi avec des répertoires contenant pas loin de 30 ISO.
Je n'ai malheureusement trouvé aucun moyen de dire à Nautilus de ne pas tenter d'ouvrir tous les fichiers d'un montage. Il pense bêtement que ce sont des fichiers locaux, et essaye de les indexer pour faire les vignettes ou autres !

Après si les fichiers accédés sont par exemple des bases de données, comme les accès ne sont pas séquentiels mais aléatoire, 1fichierfs n'est pas adapté... et aucun logiciel en réseau ne le sera !
... mais cela dit, ça ne devrait pas planter !..

Le nouveau "moteur" en cours de préparation devrait marcher mieux pour ces cas. La limite est à 32 streams et le code est plus "propre" (sans locks complexes et propice à des bugs!)

Dernière modification par Zakhar (Le 28/01/2022, à 18:52)

sefaaras · Le 28/01/2022, à 20:12

Merci de votre attention, l'identification du réseau a résolu le problème.

Zakhar · Le 28/01/2022, à 20:28

Cool alors !

L'ancien "moteur de lecture" est un peu bancal et a des bugs connus (race conditions) surtout à la lecture de plusieurs fichiers. Le nouveau "moteur" devrait être plus stable.

Dernière modification par Zakhar (Le 28/01/2022, à 20:29)

sefaaras · Le 29/01/2022, à 14:24

Actuellement, la connexion entre le disque local et le disque distant est interrompue. J'ai écrit un bash qui se remonte automatiquement. Mais quelle pourrait être la raison de cette déconnexion ? Moyenne (15 minutes - 2 heures)

Zakhar · Le 29/01/2022, à 16:24

Tu veux dire 1fichierfs se plante ? Je ne peux pas te dire sans voir une trace, voire trace-debug.

S'il ne se plante pas mais simplement tu ne peux plus rien lire, ça peut venir d'un bannissement côté 1fichier.com.

Par exemple tu utilises plusieurs IP :
- tu as passé ton compte à d'autres; ça c'est la triche que le bannissement évite, et 1fichierfs ne peut rien faire si tu as "triché" ainsi !..
- ou sans tricher, 1fichierfs n'a pas été "forcé" en ipv4 et tu l'as mis sur plusieurs machines chez toi qui ont chacune une ipv6 différente (normal !) 1fichier.com interprète alors ça comme de la triche, bien que ça n'en soit pas. C'est pourquoi l'option -4 est pratique à mettre sur tous les appareils derrière ta box, histoire que 1fichier.com ne pense pas que tu "triches".

Dernière modification par Zakhar (Le 29/01/2022, à 16:25)

bobo15995 · Le 05/02/2022, à 01:59

Merci Zakhar pour ce magnifique développement ! Je viens de le découvrir ce soir et il fonctionne impeccablement bien. Cela m'a redonné goût à 1fichier (faut dire que leur interface n'est pas des plus pratiques... ) !

J'essaie (j'y ai passé la soirée et presque la nuit haha) d'utiliser 1fichierfs avec Kodi (équivalent de Plex évoqué dans d'autres commentaires). Cela fonctionne parfaitement bien à l'exception d'un petit problème : l'arrivée de nouveaux fichiers à importer.

J'explique mon user case :

- La Raspbery Pi a monté son dossier 1fichier, avec la commande suivante :

1fichierfs . --api-key=@~/.1fichier.key -o allow_other -o default_permissions -o auto_unmount --refresh-time=1  --log-level=7 --log-file=/tmp/debug.tx

- La Raspberry Pi a lancé Kodi pour la première fois et importé toutes les vidéos contenues dans le dossier 1fichier

Plusieurs jours passent.

- Un autre utilisateur ajoute un fichier vidéo directement depuis le site 1fichier.com
- Sur la RPi, l'auto-refresh détecte au bout d'une minute maximum le nouveau fichier (j'ai vérifié dans les logs ça fonctionne bien, et je trouve en effet la nouvelle vidéo avec l'explorateur de fichiers)

Mais Kodi ne détecte malheureusement pas le nouveau fichier

J'ai essayé avec des dossiers normaux et la détection de nouveaux fichiers se réalise parfaitement sur Kodi. J'en déduis que c'est dû à la particularité de ce dossier monté avec 1fichierfs. Mais je n'ai aucune idée d'où vient le problème... Les logs de 1fichierfs ne semblent lister que les appels à l'API de 1fichier. Est-ce qu'il n'y aurait pas moyen de loger les accès aux dossiers ? (Pour essayer de comprendre pourquoi Kodi ne détecte pas les nouveaux fichiers dans ce dossier)
J'essaie de creuser du côté des logs de Kodi mais ils ne semblent pas être plus bavards...

Merci d'avance pour votre aide

Zakhar · Le 05/02/2022, à 09:20

Bonjour bobo15995, et merci pour ton intérêt pour 1fichierfs

Oui, j'utilise moi-même 1fichierfs avec mon Kodi sur mon Raspberry Pi. C'est idéal pour éviter d'avoir à encombrer le Pi de disques externes en USB. Le Pi a ainsi virtuellement plus de 2To de stockage.
Cependant, comme c'est moi qui mets les sauvegardes et les média sur mon stockage cloud, je fais aussi les rajouts "à la main" (avec le menu "Rajouter à ma médiathèque") un par un des nouveaux éléments. C'est tolérable pour mon usage.

Pour l'automatisme que tu évoques, la piste est sans doute celle-ci : https://manpages.ubuntu.com/manpages/fo … ify.7.html

J'avoue que je n'ai jamais exploré la question.
Si ça se trouve fuse lui-même n'est pas compatible avec ce mécanisme... j'espère que ce n'est pas le cas.
Peut-être que fuse est compatible et qu'il n'y a rien d'autre à faire que mettre les choses en place de ton côté.
Peut-être aussi que le driver fuse (1fichierfs) doit "faire des choses" pour être compatible avec inotify.

... je te laisse regarder la piste de ton côté, et je creuse du mien. On se tient au courant !

[EDIT] Bon, en réalité inotify seble marcher "out of the box" pour fuse (du moins sur Ubuntu, pas encore essayé sur mon Raspbian)
Test réalisé :

$ inotifywait -m -r ~/1fichier
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
/home/zakhar/1fichier/ OPEN .stats
/home/zakhar/1fichier/ ACCESS .stats
/home/zakhar/1fichier/ CLOSE_NOWRITE,CLOSE .stats
(...)
/home/zakhar/1fichier/.crypt/iEE0h1qoz91fwDr4t3CAKJna/ OPEN,ISDIR 34u8NwF5-FwVdV,cgvTm314b
/home/zakhar/1fichier/.crypt/iEE0h1qoz91fwDr4t3CAKJna/34u8NwF5-FwVdV,cgvTm314b/ OPEN,ISDIR 
/home/zakhar/1fichier/.crypt/iEE0h1qoz91fwDr4t3CAKJna/ ACCESS,ISDIR 34u8NwF5-FwVdV,cgvTm314b
/home/zakhar/1fichier/.crypt/iEE0h1qoz91fwDr4t3CAKJna/34u8NwF5-FwVdV,cgvTm314b/ ACCESS,ISDIR 
/home/zakhar/1fichier/.crypt/iEE0h1qoz91fwDr4t3CAKJna/ ACCESS,ISDIR 34u8NwF5-FwVdV,cgvTm314b
/home/zakhar/1fichier/.crypt/iEE0h1qoz91fwDr4t3CAKJna/34u8NwF5-FwVdV,cgvTm314b/ ACCESS,ISDIR 
/home/zakhar/1fichier/.crypt/iEE0h1qoz91fwDr4t3CAKJna/ CLOSE_NOWRITE,CLOSE,ISDIR 34u8NwF5-FwVdV,cgvTm314b
/home/zakhar/1fichier/.crypt/iEE0h1qoz91fwDr4t3CAKJna/34u8NwF5-FwVdV,cgvTm314b/ CLOSE_NOWRITE,CLOSE,ISDIR 
/home/zakhar/1fichier/ OPEN,ISDIR .crypt
/home/zakhar/1fichier/.crypt/ OPEN,ISDIR 
(...)

Si inotitfywait n'est pas installé, ça te dira comment l'obtenir :

sudo apt install inotify-tools

Donc sans n'avoir rien à faire sur le driver, le kernel semble bien "notifier" des événements sur le filesystem.

Alors peut-être que Kodi utilise autre chose... à explorer !

Par exemple sur comment tu fais ça avec Kodi... addon Watchdog, version Kodi 19 il semble y avoir des bugs de l'addon dû au passage à Python 3 par exemple.

Dernière modification par Zakhar (Le 05/02/2022, à 09:55)

bobo15995 · Le 05/02/2022, à 12:11

Bonjour Zakhar,

Merci pour ta réponse. C'est amusant d'avoir le même cas d'usage !

Où se trouve le bouton "Ajouter à la médiathèque" sur Kodi ?
Car à la limite, on pourrait faire un script avec inotify pour exécuter l'action "ajouter à la médiathèque" depuis l'API de Kodi. Mais bon niveau utilisation des ressources pour une Raspberry c'est pas top, je comptais faire juste un refresh au lancement de la raspberry (car je la coupe quand je l'utilise pas).

J'ai essayé plusieurs choses :
- Activer le refresh de la librairie au démarrage de Kodi. Quand je le lance, il cherche en effet les nouveautés mais il ne les trouve pas. Pourtant les logs de Kodi n'évoquent aucune erreur.
- Lancer manuellement un refresh par l'API

curl --data-binary '{ "jsonrpc": "2.0", "method": "VideoLibrary.Scan", "id": "mybash"}' -H 'content-type: application/json;' http://<User>:<Password>@<hostname>:<port>/jsonrpc

Le refresh de Kodi est bien lancé mais une fois de plus il ne trouve pas les nouveaux fichiers.

Je vais essayer de creuser pour avoir des logs Kodi plus détaillés car ils ne racontent pas grand chose...

Autre chose importante à notifier, même sans refresh, quand je vais dans Paramètres > Media > Videos > Nom de la Source
Je vois les nouveaux fichiers... Extrêmement étrange. Et même en faisant un reload, il ne les importe pas dans la bibliothèque. Je suis obligé de supprimer la source, la recréer pour qu'ils apparaissent enfin !

Aussi, j'ai downgradé Kodi sur la version 18.9 et le refresh de la librairie ne fonctionne pas non plus...

Zakhar · Le 05/02/2022, à 13:04

Oui, c'est étrange que Kodi n'indexe pas des fichiers que tu vois bien avec un ls !..

Si je comprends bien, tu procèdes comme moi en éteignant le Pi quand tu n'en as plus besoin, et l'indexage au démarrage te suffirait.

Donc dans ce cas, la piste inotify n'est pas à creuser.
Aussi inotify ne peut pas marcher en réalité si tu espères une indexation à la volée. En effet, à l'issue du refresh-time... il ne se passe absolument rien de visible sur les répertoires (comme indiqué dans le man !). Tout ce qu'il se passe c'est que l'arborescence mémorisée localement est simplement marquée "invalide". Ce sont seulement les accès suivants aux répertoires qui vont déclencher le réel "refresh". Aussi, comme le fichier nouveau "apparaît" dans le répertoire sans qu'il n'y ait eu aucune écriture de ce fichier (il a été posé de façon "externe"), je ne suis pas sûr de ce que inotify peut voir !..

Je pense à un truc qui est possible par rapport à ce que tu expliques : Kodi se baserait sur la date du répertoire !..

Pour 1fichierfs, la date du répertoire provient de celle qui est enregistrée dans le serveur le jour/heure où le répertoire a été créé, et donc ne change jamais.
Sur un filesystem standard, un répertoire est en fait un objet qui contient une liste d'entrées (fichiers et sous-répetoires) et sa date varie dès que le contenu change.

Pour tester si c'est bien ça je te propose de faire le test suivant :
Dans ton montage 1fichier :
- créer : répertoire1
- mettre un fichier dans le répertoire
- indexer
- mettre un second fichier
- constater que ça n'indexe pas
- arrêter Kodi
- créer : répertoire2 (il aura donc une date plus récente que répertoire1)
- déplacer les deux fichiers de répertoire1 dans répertoire2 (à la souris ou commande mv)
- supprimer répertoire1
- renommer répertoire2 en répertoire1
- vérifier si là l'indexation marche en relançant Kodi et en indexant (ou API) ?

Si la manipulation fonctionne, il y a (au moins) 3 solutions :
- Voir s'il y a moyen de dire à Kodi de ne pas se baser sur la date du répertoire, mais réellement relire celui-ci (dans les paramètres expert/avancé, c'est un peu la jungle Kodi tant il y a de paramètres partout ?)
- Faire un script avant lancement de Kodi qui fait le contournement indiqué plus haut sur les répertoires qui sont des "sources". Le script pourrait avoir gardé "l'état précédent" des sources et ne faire le renommage qui si l'état a changé. Cela revient à pallier à l'insuffisance de Kodi si celui-ci ne sait que se baser sur la date du répertoire.
- "Patch" de 1fichierfs pour calculer la date du répertoire en fonction du fichier/répertoire le plus récent qu'il contient [pas satisfaisant à 100% à cause précisément des "renommages/déplacement", mais marcherait sans doute dans ton cas @bobo15995]

Dernière modification par Zakhar (Le 05/02/2022, à 13:43)

bobo15995 · Le 05/02/2022, à 14:02

La manipulation fonctionne !!! MERCI infiniment !

Grâce à toi (et le fait de comprendre que c'était la date de modification du dossier), j'ai cherché dans ce sens et j'ai trouvé le paramètre à modifier dans Kodi :

Il faut créer un fichier advancedsettings.xml dans le dossier userdata de Kodi et définir le paramètre usefasthash à false

<advancedsettings>
    <videolibrary>
        <usefasthash>false</usefasthash> <!-- defaults to true. Set to false in order to skip hashing based on the folders modification time. -->
    </videolibrary>
</advancedsettings>

Source: https://kodi.wiki/view/Advancedsettings … deolibrary

Il me reste plus qu'à ENFIN savourer un bon film ! Enfin... comme tu dis... il me reste encore beaucoup de paramètres Kodi à regarder

Complètement HS :

Tu as quelques addons à me conseiller ?

Tu utilises des addons comme vStream pour trouver tes films de vacances ou tu les ajoutes tous à la main ?

Zakhar · Le 05/02/2022, à 14:18

C'était donc bien ça !

bobo15995 a écrit :

 based on the folders modification time.

Par défaut Kodi se base sur la date de changement du répertoire, ce qui fait du sens pour des répertoires locaux !

Ravi que Kodi ait le "bon" paramètre, parce qu'un patch dans 1fichierfs n'aurait pas été "à 100%" vu que c'est un montage réseau, et qu'il peut se passer plein de choses à l'insu de 1fichierfs. Par exemple, comme tu le citais, quelqu'un qui te rajoute un fichier dans les partages qu'il t'a donnés alors que 1fichierfs n'est même pas monté. 1fichierfs verra alors ce nouveau fichier au démarrage, mais comme il ne garde pas "l'état précédent des répertoires", rien ne peut lui dire que le fichier est nouveau. Même en faisant un algo pour prendre la date du dernier fichier comme date du répertoire, il est possible que la date ne change pas si le partage qu'on t'a rajouté a été fait par renommage/déplacement d'un fichier déjà ancien.
La seule chose qui aurait été réaliste et simple est de ne plus lire la date des répertoires sur le serveur, mais prendre celle du répertoire racine de montage (~/1fichier chez moi). Ainsi un "touch" sur la racine avant de monter aurait résolu la chose.

Pour Kodi, désolé, j'ai un usage très basique, et ce sont uniquement mes propres films de vacance !

Je suis toujours en Raspberry Pi 32bits (Buster) et la version de Kodi, celle des "dépôts officiels" semble bloquée là à la 18.7, mais elle marche parfaitement alors qu'au début du Raspberry Pi4 (je l'ai acheté presque à sa sortie) Kodi plantait pas mal surtout au démarrage !..

Je dois avoir juste un add-on qui permet de regarder les chaînes de télé publiques (France 2, etc...) mais je ne m'en sers quasi jamais.

J'avais mis l'add-on Youtube, mais celui-ci est désormais H.S. depuis qu'il faut se connecter avec son propre compte...

Sinon le Raspberry Pi me sert aussi à uploader les films de vacances que mon cousin me partage sur Uptobox. Je les prends de Uptobox et les upload sur 1fichier via 1fichierfs à l'aide d'un script. C'est dommage que mes cousins préfèrent Uptobox à 1fichier... mais bon, le script marche bien et quand il tourne sur le RPi ça consomme peu d'électricité !
Et quand le cousin fait des gros films format ISO, genre la taille d'un BluRay, découpés en plusieurs .rar, le Raspberry Pi fait l'upload de tous les bouts puis automatiquement le unrar, et tout ça via 1fichierfs.
Ça prend un peu de temps (je suis pas abonné à Uptobox) mais ça tourne tout seul la nuit sur le RPi et le matin tu as le beau .ISO tout prêt !

[Edit] PS, maintenant que j'y pense, j'avais constaté aussi ce fonctionnement bizarre de non-mise à jour en rajoutant des épisodes dans des séries de vidéos familiales... donc j'emprunte volontiers le réglage "advancesettings" pour voir si la MàJ se fait sans devoir la faire 1 fichier à la fois !

Dernière modification par Zakhar (Le 05/02/2022, à 15:43)

bobo15995 · Le 06/02/2022, à 03:05

Je n'imagine pas en effet la galère que ça serait à implémenter... que de temps épargné !

Ravi que cela puisse te servir également

Zakhar · Le 06/02/2022, à 08:41

Faire en sorte que les sous-répertoires aient tous la date et heure de la racine du montage est très simple à implémenter, c'est d'ailleurs ce que fait astreamfs, le projet "parent". Ça aurait été le premier contournement simple !
En fait la date/heure du répertoire de montage est déjà connue puisque le driver doit la retourner quand on lui demande "/", racine, en l'occurrence celle du montage. En effet, 1fichier.com ne donne pas de date/heure pour la "racine" du compte !.. On aurait pu imaginer qu'ils le fassent, ça aurait donné l'âge du compte, mais non, ça n'y est pas, et non plus sur certains partages (logiquement si on partage la racine). Donc pour les répertoires qui n'ont pas de date/heure retournée par le serveur, on fait déjà ça en fait.

C'est même plus simple que l'algo actuel qui doit interpréter le JSON du serveur pour déduire la date/heure des répertoires !
Mais il aurait fallu aussi rajouter une option de plus pour faire un algo ou l'autre.

Par contre un truc qui serait plus galère à implémenter c'est gérer proprement la date d'accès et de modification tant que le driver tourne. En effet, tel que fonctionne le programme actuellement, lorsqu'un contenu de répertoire est marqué comme "invalide", l'accès suivant déclenche une nouvelle lecture du répertoire depuis le serveur, mais l'ancien état du répertoire est purement et simplement "oublié".
Gérer les dates en accès et modification voudrait dire qu'à ce moment, avant "d'oublier", on devrait comparer l'ancien et le nouveau contenu, et récupérer au passage les dates d'accès/modification des fichiers présents dans ancien/nouveau.
Pas insurmontable, mais ça fait effectivement un travail plus conséquent que simplement propager la date de la racine !
Et toujours pas parfait à 100% puisqu'il s'agit d'un montage réseau, on ne couvre pas bien avec ça le cas que tu citais de quelqu'un qui t'a rajouté dans un partage un fichier qui a une date ancienne (rajouté par déplacement), ou même si tu t'amuses à supprimer un fichier sur 1fichier.com (web) pendant que le driver tourne. Donc l'algo se complexifie si on se rend compte qu'il y a eu une modification qui n'est pas passée par le driver, parce qu'on ignore alors la date de modification, on peut juste l'approximer quelque part entre les deux rafraîchissements.

Donc c'est très bien que Kodi ait l'option en définitive.

Parce que sinon, tu vois, avant de foncer à coder un truc, il aurait déjà fallu penser aux diverses solutions et options avec leurs avantages / inconvénients !

Dernière modification par Zakhar (Le 06/02/2022, à 08:59)

bobo15995 · Le 06/02/2022, à 18:04

Je rebondis sur ta réponse car j'ai une machine sous Windows 10 (j'ai bien vu ta citation de Linus Torvald sur le forum ) et j'aimerais bien essayer ton outil dessus.

Je peux compiler une version pour Windows à partir des sources ou je dois passer par WSL2 ?

EDIT vu la première ligne du Makefile (appel à un .sh) ça ne semble pas compatible Windows

EDIT je viens de relire le 1er post qui mentionne en effet qu'il faudrait passer par WSL2. Je vais essayer cela, je te tiens au courant

Dernière modification par bobo15995 (Le 06/02/2022, à 18:11)

Zakhar · Le 06/02/2022, à 18:51

Oui, si tu as un retour via WSL2 ce serait intéressant !

A priori, si tu mets une Ubuntu 20.04 dans la WSL2, même pas besoin de compiler, tu peux prendre le package tout fait sur le PPA si tu souhaites. Compiler présente un intérêt si tu veux générer une version DEBUG car pour faire léger, les versions packagées n'ont pas le code de debug.

Une version DEBUG s'obtient simplement en faisant :

make -B 1fichierfs DEBUG=1

Tu pourras alors aller jusqu'au niveau 7 de trace, mais dans ce cas là, envoie la trace dans un fichier (--log-file=/tmp/nom.de.fichier) sinon ça va flinguer la syslog dès que tu feras quelques accès !

En fait je ne vois pas pourquoi ça ne marcherait pas dans le Ubuntu "guest" puisque WSL2 est en réalité un hyperviseur de machine virtuelle.
Mais ce qui est intéressant c'est d'arriver à faire bénéficier la partie "Window$" du montage 1fichierfs. Pour ça, une méthode est de ré-exposer le montage en SMB, donc comme un "partage Windows"... Il te faudra potentiellement jouer du allow-other pour ça.

Après, la performance quand on est côté W$ risque d'être assez calamiteuse, c'est ça qu'il faut observer !..

Et non, il n'y a pas et il n'y aura pas de version W$ de ma part pour la bonne est simple raison que le driver utilise fuse qui est unique à Linux.
Il existe une version totalement compatible sur Mac, mais ça a tellement de succès que le gars qui s'en occupait a dû la passer en licence commerciale car il ne pouvait plus suivre le rythme en mode "hobby". Mac est aussi beaucoup plus près de Linux étant anciennement POSIX, et les quelques "linuxeries" pourraient sans doute être remplacées pour faire tourner sur Mac.
Sur W$ il n'y a rien d'équivalent à fuse. Quelques tentatives existent mais elles sont très incompatibles avec fuse et obligeraient à pas mal de ré-écriture.
Comme après tout c'est open source, si tu veux te lancer dans un portage W$ natif avec les ré-écritures nécessaires, ça reste possible !

Pour être complet il existe rclone qui a un "plugin 1fichier" et qui est aussi en W$ natif.
C'est sans doute moins "détaillé" que 1fichierfs car rclone est un truc générique à plein de stockage en ligne.
Le principe est aussi un peu différent, rclone utilise un espace local sans lequel il devient très pauvre, mais qui lui permet des choses même pas envisageable avec 1fichierfs comme l'écriture aléatoire (forcément puisque tu écris d'abord localement avant d'uploader le tout !).
1fichierfs, lui, utilise zéro espace local... ce qui le rend très chouette sur une RPi !..

Dernière modification par Zakhar (Le 06/02/2022, à 19:10)

bobo15995 · Le 06/02/2022, à 22:24

Je viens d'essayer dans WSL2 et cela fonctionne très bien (sous certaines conditions) !
Il faut en effet rester dans l'environnement fichiers Linux, par exemple ~/1fichier/. On peut alors grâce au 9P protocol file server proposé par WSL2 accéder aux fichiers depuis l'environnement Windows. En ouvrant l'explorateur Windows, j'ouvre le dossier \\wsl$\Ubuntu\home\me\1fichier et je peux ouvrir avec VLC (installé sur Windows) un film

Par contre si je monte le dossier /1fichier dans l'environnement fichiers de Windows, comme /mnt/c/Documents/1fichier/, aucune erreur n'est affichée mais je ne vois aucun fichier dedans.

Aussi, ce qui m'embête, c'est que quand je spécifie comme dossier \\wsl$\Ubuntu\home\me\1fichier dans Kodi, il affiche une popup disant que ce dossier est inaccessible...
Je pourrais installer Kodi dans WSL2 mais pour avoir une interface graphique c'est pas top après
Il faut peut-être que je me tourne vers cette solution de réexposer le montage en SMB, mais je ne sais pas comment faire. Aurais-tu une technique à me recommander ?

EDIT j'ai compilé 1fichierfs avec DEBUG=1 pour comprendre pourquoi dans le dossier /mnt/c/Documents/1fichier/ les fichiers n'apparaissaient pas. Et en analysant les logs, aucune différence comparé à ceux pour le dossier ~/1fichier/ (qui pourtant lui fonctionne).
Dans les deux cas, j'arrive à la ligne suivante sans erreur avant :

[1fichierfs     0.380] DEBUG: unlock(0x557f61c2d300) 999

J'en déduis que le problème n'est donc pas visible dans les logs...

EDIT Ce qui est étonnant c'est que les logs montrent que tous mes fichiers sont bien trouvés et qu'il y a bien des instructions d'écriture, par exemple :

[1fichierfs     0.380] NOTICE: writing with FTP user `1fichierfs-187f6420xxxxxxx` in directory `/.upload.1fichierfs`.

Pourtant, aucun dossier...
C'est peut-être le fait que /mnt/c/Documents/1fichier/ est déjà issu du montage de C://Documents/1fichier ?

Dernière modification par bobo15995 (Le 06/02/2022, à 23:14)

Zakhar · Le 07/02/2022, à 07:49

Merci de ton retour bobo15995 !

Oui, on rentre sans doute dans des spécificité W$ sur lesquelles je ne vais guère pouvoir t'aider.

Pour SMB non plus, comme je n'ai aucune machine W$ à l'horizon depuis quasi 15 ans, je me suis désintéressé de ce protocole. Mes partages, par exemple avec le NAS (Synology) sont en NFS.

Vérifie cependant que l'utilisateur qui monte le répertoire 1fichierfs a les droits pour le faire. Je pense quand même que si ce n'était pas le cas, fuse te le dirait !

Niveau performance, via 9P, c'est donc "suffisant pour VLC" ce qui est déjà pas mal. Essaye une copie pour voir à quel niveau tu arrives par rapport à du Linux natif.

Edit : la ligne qui te dit comment il écrit ne signifie pas une écriture ! Elle est posée au démarrage, et c'est juste une indication pour éviter que l'utilisateur n'efface "à la main" les éléments nécessaires : le répertoire d'upload et le compte ftp utilisé.

Tu peux lancer en console le driver en mode "debug" (option -d), il va alors rester en premier plan et montrer plein de choses qui ne sont pas dans le journal.
Tu tentes la connexion côté W$, et tu vois si ça fait des accès dans le mode debug.
Pour couper, pas besoin de fusermount -u, il suffit d'un bon CTRL-C à la console !..

En effet, certains appels ne sont pas implémentés car on n'en a pas besoin communément sur Linux, il est possible qu'il y ait des besoins pour des cas particuliers.

Exemple, sur Linux, quand tu supprimes un fichier via Nautilus, celui-ci n'est pas réellement supprimé mais mis "à la corbeille". Il est donc déplacé (.Trash-1000) et un petit fichier est créé pour indiquer l'emplacement initial de ce qui a été mis à la corbeille histoire de pouvoir "récupérer". Nautilus écrit ce petit fichier, mais a besoin de le lire immédiatement pour vérifier que tout va bien et que le fichier sera récupérable. Pour que cela puisse fonctionner, il y a un "hack" dans 1fichierfs, sinon il faut attendre au moins 5 minutes (le temps FTP incompressible) pour pouvoir relire un fichier écrit. Le "hack" est que tout fichier écrit inférieur à 4096 octets est gardé en mémoire le temps que l'écriture soit réellement faite. Lorsque l'écriture est sur le "cloud", la sauvegarde locale des premiers 4096 octets est supprimée.
Il y a donc peut-être des "patterns d'accès" qui échouent avec le "double montage" sous W$... mais encore faut-il comprendre lesquels... et vu les "secrets" qui entourent W$ (normal, logiciel propriétaire, pas de documentation sur le fonctionnement interne !) c'est pas une mince affaire

Dernière modification par Zakhar (Le 07/02/2022, à 14:28)

bobo15995 · Le 07/02/2022, à 19:52

Merci également pour ta réponse.

J'ai donc relancé 1fichierfs avec l'option -d pour avoir plus de détail.

Le montage depuis WSL2 sur /mnt/Documents/1fichier/ ne génère aucune erreur dans les logs. D'ailleurs, quand on liste les documents dans ce dossier depuis WSL 2, les fichiers apparaissent, et les logs montrent en effet que quelqu'un accède au dossier.

Par contre, quand j'ouvre le dossier dans l'explorateur Windows (ou dir depuis cmd), aucun fichier n'apparaît mais surtout aucune nouvelle ligne dans les logs. Il ne se passe rien ! C'est comme si personne n'essayait d'accéder au dossier.

Je déteste également Windows

Là, je vois pas d'où ça peut venir...

Zakhar · Le 07/02/2022, à 20:16

bobo15995 a écrit :

C'est comme si personne n'essayait d'accéder au dossier.
Je déteste également Windows
Là, je vois pas d'où ça peut venir...

C'est que sans doute personne n'y accède !
Le mode "debug" est super verbeux, tu as dû le constater, s'il se passer quelque chose, crois moi tu le verrais !

Je n'ai pas beaucoup cherché sur W$ (manque d'intérêt pour la chose !) mais il semblerait que le montage côté W$ attende un périphérique de bloc géré dans un format connu par W$, lequel comporte maintenant ext4 donc !

A mon sens, il te reste la piste SMB... bon courage, surtout le partage dans le sens guest vers host n'est jamais simple...

Enfin, tu as déjà un accès avec "Plan9", c'est pas si mal en fait, même si c'est moins pratique qu'un truc "mappé sur une lettre de volume".

Dernière modification par Zakhar (Le 07/02/2022, à 20:18)

bobo15995 · Le 07/02/2022, à 20:43

Plan9 (W$) fait largement le boulot pour le coup !

C'est juste Kodi qui ne veut pas accéder à ce dossier... C'est vrai que c'est peut-être plutôt de ce côté là que je devrais creuser !

Zakhar · Le 07/02/2022, à 20:45

Tu peux toujours essayer le driver en mode full debug (niveau 7 et option -d) et lancer Kodi pour voir s'il se passe des choses !

bobo15995 · Le 07/02/2022, à 21:04

J'utilise la commande suivante (1fichierfs compilé avec DEBUG=1) :

./astreamfs/1fichierfs ~/1fichier/ --api-key=xxx -o allow_other -o default_permissions -o auto_unmount -l 7 -d

Et quand je lance Kodi, rien n'apparaît dans les logs. Mais vraiment 0 ligne !

Les logs de Kodi affichent une erreur disant qu'il ne peut pas accéder au dossier :

XFILE::CDirectory::GetDirectory - Error getting \\wsl$\Ubuntu\home\me\1fichier\

J'essaie de trouver la lib utilisée derrière XFILE pour voir si une issue sur le sujet n'existe pas déjà...

Zakhar · Le 07/02/2022, à 21:08

Enlève default-permissions pour voir.

Cette option a pour effet que si les permissions ne sont pas correctes, c'est directement le kernel qui répond et ça ne va pas jusqu'au driver.

C'est donc une très bonne option quand tout marche, parce que ça accélère dans les cas où le driver aurait de toute façon refusé l'accès, mais quand on debug, on préfère aller voir jusqu'au driver des fois que le kernel se mêle de choses qui ne le regardent pas.

Dernière modification par Zakhar (Le 07/02/2022, à 21:09)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#351 Le 28/01/2022, à 11:30

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

#352 Le 28/01/2022, à 13:44

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

#353 Le 28/01/2022, à 18:50

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

#354 Le 28/01/2022, à 20:12

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

#355 Le 28/01/2022, à 20:28

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

#356 Le 29/01/2022, à 14:24

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

#357 Le 29/01/2022, à 16:24

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

#358 Le 05/02/2022, à 01:59

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

#359 Le 05/02/2022, à 09:20

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

#360 Le 05/02/2022, à 12:11

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

#361 Le 05/02/2022, à 13:04

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

#362 Le 05/02/2022, à 14:02

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

#363 Le 05/02/2022, à 14:18

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

#364 Le 06/02/2022, à 03:05

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

#365 Le 06/02/2022, à 08:41

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

#366 Le 06/02/2022, à 18:04

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

#367 Le 06/02/2022, à 18:51

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

#368 Le 06/02/2022, à 22:24

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

#369 Le 07/02/2022, à 07:49

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

#370 Le 07/02/2022, à 19:52

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

#371 Le 07/02/2022, à 20:16

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

#372 Le 07/02/2022, à 20:43

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

#373 Le 07/02/2022, à 20:45

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

#374 Le 07/02/2022, à 21:04

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

#375 Le 07/02/2022, à 21:08

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

Pied de page des forums