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

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

Je viens d'enlever l'option et toujours aucune ligne dans les logs...
C'est comme si il ne se passait rien (je précise que j'ai vérifié à plusieurs reprises que j'étais dans le bon dossier !)

Zakhar · Le 07/02/2022, à 22:19

Bah alors là j'ai plus d'idée... désolé !

Avec W$ il y a toujours tourner 3 fois autour de la chaise dans le sens anti-horaire qui est un bon grigri et que tu peux essayer.

Attention à ne pas te tromper de sens, si tu as fait 3 fois dans le sens horaire, il faudra faire 6 fois dans l'autre sens, les trois premières fois pour annuler l'erreur !

bobo15995 · Le 08/02/2022, à 00:03

ENFIN ! Cela fonctionne !

La solution :
Utiliser 1fichierfs dans /home/me/1fichier
Ouvrir dans l'explorateur Windows l'adresse \\wsl$
Clic droit sur Ubuntu > Connecter à un lecteur réseau > Lecteur Z par exemple

Puis dans Kodi, ajouter une source, on sélectionne le dossier dans Z:\home\me\1fichier

Encore merci Zakhar pour cet outil qui se veut décidément très cross-platform

Zakhar · Le 08/02/2022, à 08:34

Merci pour tes tests @bobo15995 !

Je vais pouvoir indiquer que ça fonctionne avec W$ sur le premier post en renvoyant à tes explications.

Et oui en effet, WSL/WSL2 m'a bien amusé quand ça a été annoncé, en fait c'est le Wine à l'envers, et la bonne preuve que W$ est en train de tout doucement s'enfoncer dans la non pertinence (irrelevance in English).
Et avec le même raisonnement que les éditeurs de jeux ne se fatiguent pas à faire des versions "natives Linux" puisque Wine existe et fonctionne bien, ça présente moins d'intérêt... sauf précisément "peformances" de faire une implémentation native W$ d'un driver Linux.
C'est la raison pour laquelle je te demandais quelle "performance" on atteint via le montage W$ ?

Sur ma machine native Ubuntu, j'atteins facilement les 100Mo/s en download, c'est à dire saturation de ma ligne fibre.
Donc si par exemple tu es à 80Mo/s sur Linux et à 8Mo/s via le montage W$... eh bien là il y a une dégradation qui pourrait justifier que quelqu'un (pas moi !) se fatigue à faire un "montage natif".
Si par contre c'est plutôt de l'ordre 80Mo/s en Linux natif et 70Mo/s via Z: ... bah là ça vaut même pas la peine de se fatiguer.

Tu as donc bien déduit, pour refaire ce que W$ a bien fait... vu qu'on peut faire tourner du Linux natif et l'exposer sur l'hôte W$, ça ne vaut plus la peine de se fatiguer à faire de W$ natif... notamment se battre avec les documentations et exemples de code inexistants sous W$ sous prétexte de logiciel propriétaire !

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

bobo15995 · Le 08/02/2022, à 09:25

C'est une bonne question (le débit de download).
Je vérifie ça demain soir. Je te tiens au courant.

Bonne journée

Zakhar · Le 08/02/2022, à 09:29

Oui, le débit "absolu" dépend de ta machine et de ta connexion, mais ce qui est intéressant est "l'overhead" créé par la traversées de différentes "couches" pour arriver jusqu'à W$ !..

EDIT: post #1 modifié pour indiquer le fonctionnement correct via WSL2. Merci encore bobo15995

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

bobo15995 · Le 10/02/2022, à 00:22

Génial si ça peut en aider d'autres

J'ai fais les tests que tu m'as demandé.

- Ubuntu natif : le fichier se télécharge à 6Mo/s en moyenne (oui ce soir sur 1fichier ça télécharge pas rapidement... )
- WSL2 : le fichier se télécharge à 5.5Mo/s en moyenne, mais l'accès au fichier depuis Windows (donc par la passerelle P9 wsl$) accède au fichier avec un débit de 3Mo/s en moyenne.

La chose à retenir c'est qu'un accès par Windows divise donc le débit de téléchargement par 2 !

Zakhar · Le 12/02/2022, à 10:43

Merci @bobo15995

Tu n'as pas une vitesse native fameuse... mais ça suffit pour du 1080p standard, y compris avec le "ralentissement" W$, c'est l'essentiel !

bobo15995 · Le 23/02/2022, à 22:07

Bonsoir,

C'est à nouveau moi ! Encore merci, j'utilise 1fichierfs très souvent et cela fonctionne parfaitement
Enfin... jusqu'à hier soir, où j'ai maintenant l'erreur suivante :

ERROR: http_code 403 on get_token json resp.:`{"message":"Only 1 location allowed at a time #875","status":"KO"}`

Impossible de comprendre d'où sort cette erreur.
Le topic suivant en parle également https://forum.rclone.org/t/1fichier-onl … me/23573/3 mais je n'ai pas vraiment compris comment ils résolvaient le problème.

Est-ce que tu as déjà eu ce cas ?

Bonne soirée

Zakhar · Le 23/02/2022, à 22:22

Ça m'arrive très souvent quand je n'y prend pas garde, surtout quand je ne suis pas chez moi et que j'ai laissé mon RaspPi tourner !

La réponse est dans le message d'erreur : 1fichier.com a détecté que tu télécharges des fichiers de deux endroits à la fois (en fait deux IP différentes) et bloque.

D'où cela peut venir :

Tu as donné ton ID/Mot de passe ou ta clé d'API à quelqu'un d'autre, et il télécharge en même temps que toi. Là 1fichierfs ne peut rien faire pour toi, car "donner/vendre ses accès" à quelqu'un d'autre n'est pas autorisé !
Tu n'as pas fait attention, et c'est toi qui fais deux accès à des endroits différents. C'est une chose qui m'arrive quand je laisse des choses tourner sur mon RaspPi "à la maison", et que je télécharge depuis un autre lieu. Solution : arrêter un des deux téléchargements !
Tu as plusieurs machines chez toi qui téléchargent... et c'est en IPv6... eh bien là pas de chance, 1fichier.com va détecter que c'est plusieurs endroits et bloquer. En effet, chaque machine chez toi aura une IPV6 différente, puisque c'est le principe même de l'IPV6 et donc 1fichier.com verra des "IP différentes" et croira qu'il s'agit de plusieurs lieux.

Quand je dis "télécharge" ci-dessus, il s'agit bien de "download". En réalité il n'y a pas ces règles d'IP unique pour l'upload ou les autres opérations d'API : créer des répertoires, renommages, suppressions, etc...
Et "télécharge" compte indifféremment un téléchargement réalisé depuis l'interface web officiel de 1fichier.com qu'une copie de fichier via 1fichierfs (vu du serveur c'est pareil !).

Pour le dernier cas, c'est prévu par 1fichierfs, il suffit de forcer ipv4 sur toutes tes machines, ce qui se fait par l'option -4
Ainsi, en principe ta "box" est en mode routeur, et 1fichier.com ne verra que l'adresse publique de la box quelle que soit la machine qui utilise 1fichierfs derrière la box.

La limite de cela est que si en parallèle de 1fichierfs tu utilises l'interface web standard, ton navigateur va préférer l'IPV6 s'il est prévu par ta box (par exemple Freebox) et donc tu seras vu comme "deux IP" et l'erreur ci-dessus surviendra.

C'est pourquoi je conseille dans les posts plus haut de toujours utiliser l'option -4, du moins si on a plusieurs PC chez soi avec 1fichierfs (ce qui est mon cas : PC de bureau, PC portable et Raspberry Pi, ça fait 3 machines qui downloadent !)
Bien sûr, même avec l'option -4 sur toutes les instances de 1fichierfs, si la pile ipv6 est activée et qu'on fait en parallèle un téléchargement via le navigateur, on aura tout de même l'erreur puisque 1fichier.com verra une ipv6 (navigateur) et une ipv4 (1fichierfs) et croira également qu'il s'agit de deux endroits.

Dernière modification par Zakhar (Le 23/02/2022, à 22:31)

bobo15995 · Le 24/02/2022, à 13:34

Merci pour cette réponse plus que complète !

En effet, j'ai partagé mon compte avec un autre membre de mon foyer. Il n'a pas la même IP. Mais bon... comme il s'agit de quelqu'un de mon foyer, je trouve ça vraiment exagéré de ne pas pouvoir lui partager l'accès.
C'est sur qu'après ça serait très compliqué pour 1fichier d'éviter les abus.

Je ne sais pas encore quoi faire. Entre écrire à 1fichier, utiliser un proxy/VPN ou simplement abandonner l'idée de partager mon compte.

Zakhar · Le 24/02/2022, à 14:21

bobo15995 a écrit :

En effet, j'ai partagé mon compte avec un autre membre de mon foyer.

Si c'est "ton foyer" dans le sens habitant au même endroit que toi, il/elle est "derrière la même box" et ça ne pose pas de problème de montrer la même IP à 1fichier.com

Il faut bien sûr éviter d'écouter des chansons que tu as reapé de tes CD (un de mes cas d'usage) via un smartphone connecté en 4G et en même temps utiliser 1fichierfs sur tes PC, parce que là tu auras bien 2 IP.

Par contre si "ton foyer" désigne quelqu'un de ta famille qui n'habite pas sous le même toit, au sens 1fichier.com c'est un "foyer" différent, désolé... pas la peine de leur écrire la réponse est connue !
C'est un peu pareil pour tout ce genre de services d'ailleurs.

Effectivement, juger de ce "double accès" par l'adresse IP est imparfait dans tous les sens : faux positifs (ipv4/ipv6) et faux négatifs puisqu'il y a effectivement des solutions : proxy, vpn,....

Pour des médias, d'ailleurs, la "solution" régulièrement employée pour ça est Plex. Par contre il te faut une machine dédiée (voire un hébergement) parce que ça réclame pas mal de puissance et pour être fonctionnel, il vaut mieux que ce soit du 24/24.
A défaut de machine dédiée, si tu as une Freebox, elle expose un excellent VPN, surtout depuis qu'elle permet de faire du Wireguard. J'arrive à avoir quasiment du 5Mo/s avec ma Freebox mini quand j'y accède à l'autre bout de la France. C'est un peu juste pour du "BluRay-HD", mais largement suffisant pour du 1080p standard, et bien sûr sans problème aucun pour des trucs moins gourmands comme la musique. Côté Linux, il faut un kernel 5.8 (de mémoire) pour bénéficier de Wireguard, donc soit une 20.04LTS avec hwe (ce qui est maintenant "par défaut"), soit une plus récente.

Si tu as besoin des réglages pour ne pas rediriger tout le flux Wireguard (VPN en route par défaut) je peux t'aider sur ça, je l'ai fait avec mes différentes Freebox "familiales". Ainsi sur le PC Linux de la personne de "ton foyer" à qui tu as passé ton compte, tu règles pour que seulement ce qui est relatif à 1fichier passe par Wireguard, le reste allant sur la route par défaut. En réalité je ne l'ai pas fait pour 1fichierfs (je pourrais, mais je n'en ai pas usage), d'où le fait que parfois j'aie des "403", mais j'ai fait ce principe pour accéder aux réseaux locaux de chacune des Freebox et par exemple pouvoir "dépanner la famille" sur leurs PC. Rajouter 1fichier.com dans le mix est sans doute faisable en poursuivant l'idée.

bobo15995 a écrit :

Je ne sais pas encore quoi faire. Entre écrire à 1fichier, utiliser un proxy/VPN ou simplement abandonner l'idée de partager mon compte.

Une autre idée est d'attendre la prochaine promotion, et offrir un autre compte 1fichier à la personne de ton foyer !
Même sans promotion, 22€ par an pour 2To, ça fait moins de 2€ par mois, c'est un cadeau. Aussi ça encourage cette petite équipe qui fait un bon travail en France, garanti "sans GAFA", et à qui les z'ayant-droit ne cessent de mettre des bâtons dans les roues en dépit des grandiloquents discours sur la "souveraineté Européenne".
Tu peux ensuite gérer les choses avec les "partages" que 1fichierfs sait exposer correctement de façon transparente.

Simplement à la racine du compte, celui qui reçoit le partage voit un truc du genre

Foobar on zakhar@free.fr

Qui est le répertoire partagé. 1fichierfs gère correctement les attributs de partage : lecture seule et lien cachés compris et les limites que cela impose.
Attention si tu fais un partage avec accès complet, celui qui reçoit le partage va pouvoir aussi effacer les fichiers/répertoires.

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

Jarodd · Le 27/02/2022, à 19:03

Bonjour

J'ai une petite question. J'utilise toujours au quotidien 1fichierfs pour monter mon espace et m'en servir pour y copier mes fichiers (via un script bash et rsync).

Cependant j'ai remarqué que parfois, les fichiers copiés ont des octets en moins à l'arrivée. Le problème est qu'immédiatement après la copie, cette différence n'apparaît pas ! Je m'explique :
1/ je copie le fichier toto.mp4. Sur mon pc, il fait 200 Mo. Je fais la copie depuis le gestionnaire de fichier, DoubleCommander (bien pratique pour gérer la file d'attente des copies), ou rsync, peu importe le problème reste le même.
2/ À la fin de la copie, le fichier toto.mp4 fait bien 200 Mo (je le vois dans mon montage /media/jarodd/1fichier/path/to/toto.mp4).
3/ Si je fais un diff des répertoires/fichiers, toto.mp4 n'apparaît pas dans les différents.
4/ J'attends quelques minutes
5/ Je relance un diff : toto.mp4 apparaît dans la liste des fichiers qui sont différents il fait quelques Mo de moins. Je précise que c'est une différence uniquement sur la taille qui est remontée : vu que les fichiers ne récupèrent pas l'heure originelle (ils ont toujours l'heure de la copie, et non l'heure de création du fichier source), je coche la case qui ignore la comparaison sur la date (dans le cas contraire, j'ai 100% de fichiers différents).

J'ai testé en refaisant la même copie manuellement pour être certain que ce n'est pas un problème de transfert : la copie va bien jusqu'au bout, les fichiers font le même poids à l'octet près. Parfois, la taille change, parfois non. C'est aléatoire.
Est-ce que cela pourrait venir d'une sorte de cache ? Ce cache m'indiquerait (à tort) que le fichier est bien identique à la source, mais au final il n'est pas entièrement copié dans l'espace distant ? Faut-il attendre un délai (lequel ?) entre la suppression du fichier, et la nouvelle copie ? Comment être certain que la copie se fait bien à 100%; et qu'un bout de fichier n'a pas été oublié en route ? Je n'ai que DoubleCommander pour comparer, j'ai assez confiance (je m'en sers aussi pour mes synchros sur des disques externes, pour les mêmes fichiers, et il m'affiche toujours des résultats corrects).

Je précise que pour 99% de mes fichiers, je n'ai pas le problème. Je le constate surtout pour les fichiers que je mets à jour. Vu qu'avec rsync je ne peux pas les écraser (je n'ai jamais compris pourquoi), j'efface les fichiers concernés, puis je relance une copie. Est-ce une coincidence ou pas ? Je ne sais pas, c'est juste mon sentiment : la 1e copie d'un fichier est toujours identique, par contre si je mets le fichier à jour, les coipies suivantes auront le problème de différence de taille.
Je ne sais pas quoi apporter de plus comme info (s'il y a des logs quelque part, ou une manip à faire pour confirmer ou pas).

Dernière modification par Jarodd (Le 27/02/2022, à 19:07)

Zakhar · Le 27/02/2022, à 20:37

Bonsoir Jarodd,

Tout d'abord, vérifie que tu as bien la dernière version publiée de 1fichierfs :

$ 1fichierfs --version
(...)
1fichierfs: version 1.8.4
(...)

En effet, il y avait un "bug" dans curl, une des librairies les plus utilisées au monde... dans l'upload de fichiers en FTPS quand on utilisait TLSv3.
Référence du bug de curl.

Précisément, avec ce bug (dû à curl), les fichiers uploadés étaient tronqués à la fin !

1fichierfs souffrait de ce bug de curl dans une version passée, mais cela est désormais "contourné" en faisant les upload FTPS en TLSv2 lequel ne présente pas le bug.

Au delà de ce "bug", je t'encourage à lire le manuel pour prendre connaissance des limitations de l'écriture et du cycle d'écriture d'un fichier.

man 1fichierfs

man 1fichierfs a écrit :

Écriture
1fichierfs permet d'écrire des fichiers sur le stokage distant (aussi nommé: "upload" ou "téléversement" en bon français). C'est limité à l'écriture séquentielle de nouveaux fichiers (avec un peu de
marge pour s'adapter au type d'écriture tel celui de encfs).
La ré-écriture, le rajout ou l'écriture aléatoire (au delà de la marge) ne sont pas supportés.
À cause de la façon dont le "processus de téléversement" est implémenté sur 1fichier.com, il y a quelques limitations:
- Tant que le "processus de téléversement" n'est pas terminé, les fichiers seront visibles via 1fichierfs (pas sur la page web) mais ne seront pas accessibles en lecture.
- Une fois l'écriture achevée, le fichier reste sur le serveur FTP pendant 5 minutes (cette limitation côté serveur pourrait être levée dans le futur).
- À ce moment, le transfert depuis le serveur FTP vers le stockage commence. Cela prend un certain temps, dépendant essentiellement de la taille du fichier.
- Une fois le transfert terminé, le fichier devient visible sur le répertoire de téléversement.
- Là, 1fichierfs déplace et renomme le fichier où il est attendu. A partir de ce moment, le fichier devient visible dans l'arborescence (web), mais ne peut pas être lu (il peut cependant être
supprimé ou déplacé/renommé).
- Dans la dernière étape, le serveur fait des travaux sur le fichier (probablement une vérification des sommes de contrôle). A cette phase toute tentative de lecture retourne ´File unavai‐
lable or corrupted´ (fichier non disponible ou corrompu) et la réponse à la requête de lecture est EBUSY : ´Ressource ou périphérique occupé´.
Exception : les "petits" fichiers (jusqu'à 4096 octets) demeurent lisibles tout au long du processus. Cela facilite par exemple le déplacement de fichiers vers la Corbeille avec Nautilus ou Nemo.
Opérations parallèles : a l'instar des systèmes de fichiers du kernel, il est possibe de supprimer, déplacer ou renommer un fichier à tout moment du processus de téléversement. Si le fichier est
supprimé pendant la phase d'écriture, l'écriture continuera (bien que plus rapidement car il n'est plus nécessaire d'écrire également en FTP), à moins que l'option -o hard_remove ne soit spécifiée,
auquel cas fuse répondra avec ENOENT (Fichier ou répertoire inexistant) à la prochaine requête d'écritue, sans même appeler 1fichierfs.
Note : mis à part les 5 minutes d'attente (déclenchement FTP), les étapes du processus de téléversement sont exactement les mêmes avec les autres méthodes : http ou "remote upload".
Environnement d'écriture : pour écrire sur le stockage distant, 1fichierfs a besoin de deux éléments : un répertoire pour le téléversement (nom fixe : /.upload.1fichierfs) et un sous-compte FTP,
calculé par défaut ou spécifié par l'option --ftp-user. 1fichierfs fait une "initialisation paresseuse", c'est à dire qu'il initialisera le maximum de choses en tâche de fond si une partie des élé‐
ments sont déjà présents, mais sinon ne créera ces deux éléments que si des écritures sont effectivement demandées. S'il n'y a plus d'intention d'écrire à nouveau sur le stockage distant via 1fi‐
chierfs, et si aucune écriture n'a été faite depuis le montage, il suffit de supprimer le répertoire .upload.1fichierfs et 1fichierfs supprimera alors automatiquement le compte FTP en cours d'utili‐
sation (le cas échéant) et "nettoiera" ainsi l'environnement d'écriture.
Bien que 1fichier.com ne permette pas les fichiers vides, 1fichierfs autorise leur création, par exemple via la commande touch. Créer un tel fichier vide est également suffisant pour déclencher
l'initiationsation de l'environnement d'écriture. Lorsque plusieurs instances de 1fichierfs fonctionnent en parallèle, cela peut servir pour éviter de perturber la création de l'environnement
d'écriture en la forçant sur une des instances avant de monter les autres.

Lorsque tu copies, si tu vérifies immédiatement il y a interférence de la cache du kernel qui te fait croire que tout va bien.

Donc pour vérifier, il faut toujours "dropper la cache" de cette façon :

sync; echo 3 | sudo tee /proc/sys/vm/drop_caches;

Une fois la cache "droppée" tu peux alors faire une comparaison de fichier qui a du sens !

Le fait de devoir "effacer" pour faire des copies avec rsync est normal, c'est expliqué ci-dessus : pas d'écriture aléatoire, ni "overwrite" (ré-écrire par dessus) car la fonction "truncate" n'est pas implémentée.
Il est peut-être possible de "jouer" avec les options de rsync pour qu'il évite d'essayer d'employer "truncate"...
Dans la dernière version (1.8.4) le "rename" se fait bien de façon pseudo atomique en écrasant la destination, donc l'algorithme par défaut de rsync qui consiste à copier les données dans un fichier temporaire, puis à la fin renommer, devrait fonctionner.

Pour aider tu peux déjà :
- Me donner la commande rsync que tu emploies (notamment les options que tu utilises). Si tu utilises un "front-end" graphique, il peut sans doute te donner la commande qu'il passe en tâche de fond.
- Lances 1fichierfs au moins avec les options :

--log-level=6 --log-file=/tmp/debug.txt --stat-file=.stats

ainsi en affichant le fichier spécifié, tu verras s'il y a des erreurs (cherche ERROR)
Tu peux aussi afficher les statistiques en temps réel ayant mis stat-file comme ci-dessus, ça te montrera à la volée s'il y a des erreurs :

watch -n3 cat 1fichier/.stats

- Sinon tu peux lancer en "mode debug" (--log-level=7), mais pour ça il faut recompiler le programme car le package standard n'a pas le code de debug pour être plus rapide et léger... donc essayons le reste d'abord ! Si tu mets --log-level=7 sur le programme packagé, il te dira juste qu'il n'a pas le code de debug, et qu'il emploie le niveau 6 à la place !

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

Jarodd · Le 27/02/2022, à 20:50

Hello,
Alors pour la version, je suis bien en version 1.8.4.

Pour la commande et ses options :

rsync -h --progress --stats -r -t -g -o -p -l -D -u --delete-after --delete-excluded /home/jarodd/path/to/src/ /media/jarodd/1fichier/path/to/dest/

Pour éviter de chercher dans le man :

-h, --human-readable        output numbers in a human-readable format
--progress              show progress during transfer
--stats    This tells rsync to print a verbose set of statistics on the file transfer, allowing you to tell how effective rsync’s delta-transfer algorithm is  for  your  data.   This  option  is
              equivalent to --info=stats2 if combined with 0 or 1 -v options, or --info=stats3 if combined with 2 or more -v options.
-r, --recursive             recurse into directories
-t, --times                 preserve modification times
-g, --group                 preserve group
-o, --owner                 preserve owner (super-user only)
-p, --perms                 preserve permissions
-l, --links                 copy symlinks as symlinks
-D                          same as --devices --specials (soit --devices               preserve device files (super-user only) --specials              preserve special files
-u, --update          This  forces  rsync  to skip any files which exist on the destination and have a modified time that is newer than the source file.  (If an existing destination file has a modification
              time equal to the source file’s, it will be updated if the sizes are different.)
--delete-after    Request that the file-deletions on the receiving side be done after the transfer has completed.

J'ai bien noté les options de 1fichierfs, je vais les ajouter à mon alias, j'ajouterai les logs si j'en vois apparaître.

Merci !

Zakhar · Le 27/02/2022, à 20:56

Il te manque au moins l'option -W pour copier les fichiers en entier au lieu de tenter l'algorithme par delta que rsync utilise par défaut !

Les options -l (symlinks) et -D ne sont pas utiles puisque le stockage distant 1fichier.com ne gère ni les liens symboliques, ni les "fichiers spéciaux". Si tu en as dans la source, leur copie ne fonctionnera pas puisque n'étant pas supporté par 1fichier.com, le driver ne peut pas rendre le service !

-t -g -o ne servent pas non plus puisque 1fichier.com ne gère pas la notion de user/group, quant au temps, c'est de toute façon celui où tu as fait la sauvegarde sur 1fichier.com, on ne peut pas le changer.

Par exemple, voici comment est implémenté "chown" (changement user/group)

/*
 * @brief fuse callback for chown
 *
 * This is only to avoid commands like cp, chown, etc... to complain about
 * not being able to change owner.
 * It doesn't do anything because there is nothing the driver can do to
 * alter owners since the server does not handle them.
 *
 * @param path to the file
 * @param uid to set
 * @param gid to set
 * @return 0 or error code
 */

int unfichier_chown(const char *path, uid_t uid, gid_t gid)
{
	return FAKE_CALLBACK;
}

Autrement dit, l'appel est implémenté, comme le commentaire le précise, pour éviter que les utilitaires (cp, rsync,...) râlent de ne pas pouvoir appeler la fonction, mais cela ne produit absolument aucun effet puisque 1fichier.com ne gère pas !

Tu auras forcément "la log", là où l'a spécifiée, avec le niveau 6 ça écrit des informations à l'entrée, et pour chaque fichier lu ou écrit et chaque appel d'API.
Ce qu'il faut voir c'est si tu as des erreurs ou déjà des "warnings" qui peuvent donner une piste.
Si tu ne veux que ce niveau (warning) tu peux enlever --log-level=6 puisque le défaut est --log-level=4 qui correspond à "warning", et dans ce cas tu n'as que les messages "warning" ou plus grave (erreur et critique).

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

Jarodd · Le 28/02/2022, à 19:00

Bonjour,
Merci pour les options, je les modifie.
Voici ce que j'ai trouvé dans les logs du jour :

[1fichierfs 21154.606] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 21307.824] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 21432.974] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 21541.491] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 21687.449] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 21797.686] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 21953.104] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 22046.942] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 22140.563] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 22297.929] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 22422.458] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 25050.866] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 25869.640] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 25925.257] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 25974.645] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 26014.642] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 26053.578] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 26094.983] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26138.423] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26177.628] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26213.904] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 26260.137] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26326.962] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26380.163] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26439.767] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26498.248] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26569.757] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26643.662] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 26700.582] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 26765.883] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 26835.108] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 26900.988] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 29224.458] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.
[1fichierfs 29322.039] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"status":"KO","message":"Not in manual FTP mode #195"}.
[1fichierfs 29410.340] ERROR: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.

Je ne sais pas si c'est parlant pour toi, ça ne l'est pas pour moi

Zakhar · Le 28/02/2022, à 19:50

Ça c'est une "erreur normale", d'ailleurs je devrais sans doute lui enlever son niveau "Error" effectivement.

En réalité le fonctionnement FTP peut se faire de deux façons : automatique ou "manuel".

En automatique, tout ce que tu as uploadé est considéré comme terminé quand ça fait 5 minutes que le serveur ne constate qu'un fichier n'a plus changé de taille. Le but "fonctionnel" des 5 minutes est de te laisser le temps de faire un "append" si ton upload s'est interrompu pour une raison quelconque (ce que 1fichierfs ne fait jamais !). C'est à dire reprendre l'upload où il s'était arrêté au lieu de tout recommencer.

Le mode "manuel" ne prend pas les fichiers en automatique, mais commence à compter les 5 minutes à partir du moment où le déclenchement est fait. Cela laisse donc plus de temps pour une éventuelle reprise.
Ce qui est ridicule dans le mode "déclenché", c'est qu'il attend quand même les 5 minutes... sinon on aurait pu gagner du temps à passer dans ce mode.

Donc en fait quand un upload est fini (fermeture d'un fichier écrit), 1fichierfs envoie un ordre de déclenchement.
Or lorsque l'option FTP est en en automatique, envoyer un déclenchement provoque l'erreur que tu vois, qui en fait est juste une information qui dit te rappelle que puisque le réglage n'est pas "manuel", il n'est pas utile de déclencher !

On pourrait regarder l'état du compte FTP et ne pas déclencher si en mode automatique, mais d'une cela ferait plus de code (autant déclencher systématiquement), mais surtout l'API pour regarder l'état du compte est stupidement limitée à 1 appel par 5 minutes !..
Un malin pourrait aussi objecter qu'il suffit de regarder l'état du compte au démarrage... oui mais bon, l'utilisateur peut à tout moment changer son compte d'automatique en manuel ou vice-versa, et donc cela ne serait pas une tactique certaine à 100% !..

Donc bref, rassure-toi, ce n'est pas une "erreur".

Merci du signalement car effectivement son statut "erreur" peut faire croire à un truc grave. Dans la prochaine version je vais le descendre au niveau "Information" (en dessous de "Warning").

La prochaine version aura un tout nouveau moteur de lecture amélioré.
Il fonctionne nickel sur mes PC depuis plus d'un mois.

(C'est sur le gitlab pour les courageux... ou téméraires... dans la branche improved_reader)

Par contre la partie écriture reste pour l'instant inchangée, donc pas d'amélioration de ce côté là Jarodd si toutefois tu voyais de nouveau le "bug de troncature". Ca arrivait en TLSv3 comme je l'ai écrit (et signalé à curl), mais ce "n'est pas censé"... se manifester en TLSv2, du reste je n'ai jamais constaté cette "troncature" moi-même depuis que j'ai contourné en passant en TLSv2, mais il est vrai que je fais la plupart de mes uploads en non chiffré puisque mes fichiers sont déjà chiffrés au départ (par encfs), pas besoin "d'en rajouter une couche" qui ne servirait à rien !

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

Jarodd · Le 28/02/2022, à 20:06

Ok mais alors je n'ai pas bien compris s'il y a quelque chose à faire concernant mes fichiers qui changent de taille ? Tes explications sont très techniques, et j'ai un peu de mal à suivre

Zakhar · Le 28/02/2022, à 22:22

Sur l'erreur que tu as signalée, elle n'a aucune conséquence et ne devrait pas provoquer de troncature de fichiers.

Merci de l'avoir signalé cependant, c'est maintenant changé en INFO -non plus erreur- (version future 1.9.0)

[1fichierfs     0.000] INFO: user_agent=1fichierfs/1.9.0
(...)
[1fichierfs   347.427] INFO: Ignoring: status is NOT OK, url=`https://api.1fichier.com/v1/ftp/process.cgi` name=`` response={"message":"Not in manual FTP mode #195","status":"KO"}.

Pour ton rsync, je ferais plutôt :

rsync -h --progress --stats -r -W -u --delete-after --delete-excluded /home/jarodd/path/to/src/ /media/jarodd/1fichier/path/to/dest/

Dis-moi juste si ça se reproduit, et ce que tu faisais exactement que je puisse voir si je sais reproduire.
En effet, malheureusement, la "troncature" qui se produisait en TLSv3 était "silencieuse", c'est à dire sans retour de code d'erreur.

Edit : je tâcherai de refaire des tests d'upload avec rsync un de ces jours.

Dernière modification par Zakhar (Le 01/03/2022, à 08:39)

Jarodd · Le 01/03/2022, à 09:07

Bonjour,

J'ai mis à jour les options de rsync, je posterai les détails après la prochaine synchro.
Y a-t-il quelque chose à changer pour les copies manuelles ? (cp, en GUI avec nemo, DoubleCommander,...) ? Ou bien j'attends la future màj vers 1.9.0 ?

Zakhar · Le 01/03/2022, à 17:37

Bonjour Jarodd,

En résumé : non, rien à changer !

Les copies (qu'elles soient manuelles ou en GUI) de ton PC vers le cloud (upload) ne changeront pas dans la 1.9.0 car cette partie là n'est pas modifiée du tout (pas encore en tout cas !).

Par contre les copies dans l'autre sens : récupération de sauvegarde, etc..., donc depuis le cloud 1fichier.com vers ton PC (download) devraient être plus stables et (un peu) plus rapides en 1.9.0... mais ça marche déjà fort bien en 1.8.4 et depuis 3 ans avec les versions antérieures !..

Edit : test unitaire (une copie de plusieurs giga) chiffrée -d'habitude je fais du non chiffré donc pas significatif par rapport à ton cas Jarodd- : pas de problème, fichier strictement identique avec "diff".

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

Jarodd · Le 01/03/2022, à 18:17

Très bien je te remercie.
Il faut que je m'habitue à toujours voir des différences quand je compare les répertoires Heureusement cela concerne peu de fichiers sur la totalité que je sauvegarde.

Zakhar · Le 01/03/2022, à 18:45

Oui, c'est recommandé par 1fichier.com de "tester après upload" !
Je le fais systématiquement, et depuis le passage (contournement) en TLSv2, je n'ai plus jamais constaté le "bug de troncature des fichiers".

Une fois que tu as synchronisé, tu peux afficher les statistiques pour voir quand tout est complètement fini... ou attendre un peu selon la quantité de données sauvegardées, genre 30 minutes, puis :

sync; echo 3 | sudo tee /proc/sys/vm/drop_caches;

Pour ne pas avoir l'effet de la "cache" du noyau linux qui peut te faire croire que tout va bien !

Et pour vérifier :

stdbuf -oL diff -rs /home/jarodd/path/to/src/ /media/jarodd/1fichier/path/to/dest/ | tee /tmp/comparaison.txt

Tu ne dois voir que des lignes qui disent que les fichiers sont identiques.
Pour ne pas avoir a scruter l'écran, la commande ci-dessus mettra en parallèle le résultat dans /tmp/comparaison.txt

Ensuite tu fais

grep -v 'sont identiques$' /tmp/comparaison.txt

Cela demande de chercher dans le fichier /tmp/comparaison.txt toutes les lignes qui ne se terminent pas par 'sont identiques'.

Si tout va bien, rien ne s'affiche.
Sinon tu auras

Les fichiers /home/jarodd/path/to/src/ubuntu.iso et /media/jarodd/1fichier/path/to/dest/ubuntu.iso sont différents

... et au moins tu sauras ceux qui ont échoué, et avec un peu de chance, si tu as mis une trace niveau 6, on verra quelque chose.

Une autre hypothèse est que certains fichiers que tu as sauvegardés à l'époque où il y avait le "bug" sont incorrects. La commande de comparaison ci-dessus devrait les révéler.

Dernière modification par Zakhar (Le 01/03/2022, à 21:13)

bobo15995 · Le 06/03/2022, à 22:46

Bonsoir Zakhar,
Je réponds un peu tardivement mais merci pour ta réponse très complète
En effet, un abonnement sur 1fichier sera mieux que de prendre un abonnement pour un VPN (plus cher en plus)...

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#376 Le 07/02/2022, à 21:22

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

#377 Le 07/02/2022, à 22:19

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

#378 Le 08/02/2022, à 00:03

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

#379 Le 08/02/2022, à 08:34

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

#380 Le 08/02/2022, à 09:25

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

#381 Le 08/02/2022, à 09:29

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

#382 Le 10/02/2022, à 00:22

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

#383 Le 12/02/2022, à 10:43

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

#384 Le 23/02/2022, à 22:07

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

#385 Le 23/02/2022, à 22:22

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

#386 Le 24/02/2022, à 13:34

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

#387 Le 24/02/2022, à 14:21

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

#388 Le 27/02/2022, à 19:03

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

#389 Le 27/02/2022, à 20:37

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

#390 Le 27/02/2022, à 20:50

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

#391 Le 27/02/2022, à 20:56

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

#392 Le 28/02/2022, à 19:00

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

#393 Le 28/02/2022, à 19:50

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

#394 Le 28/02/2022, à 20:06

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

#395 Le 28/02/2022, à 22:22

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

#396 Le 01/03/2022, à 09:07

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

#397 Le 01/03/2022, à 17:37

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

#398 Le 01/03/2022, à 18:17

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

#399 Le 01/03/2022, à 18:45

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

#400 Le 06/03/2022, à 22:46

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

Pied de page des forums