Forum général.cherche-logiciel Synchroniser un lecteur mp3 avec plusieurs partitions

Posté par  . Licence CC By‑SA.
Étiquettes :
0
17
déc.
2017

Bonjour,

je souhaiterais synchroniser mon lecteur mp3 composé d'un périphérique de stockage interne et d'une carte SD avec un dossier de ma machine. Le but serait d'avoir la copie exacte de ce dossier. Le problème qui est simple en apparence parait se compliquer avec ce lecteur mp3 où ma machine détecte distinctement les deux formes de stockages du lecteur mp3.
La commande fdisk -l me retourne :
- /dev/sdc pour le stockage interne
- /dev/sdd pour la carte SD

Je cherche à ce que la synchronisation remplisse le stockage interne en premier et se tourne vers la carte SD lorsque le stockage interne est rempli.

rsync (et unison) n'ont pas l'air de gérer ça nativement. Je suis parti vers un union mount : unionfs.
J'ai donc monté mes périphériques (avec un dossier Music à leur racine) et fait :

unionfs-fuse /media/pointdemontage1=RW:/media/pointdemontage2=RW dossierfusion/Music

Et j'ai utilisé rsync pour la copie. Mais ça ne fonctionne pas : rsync me renvoie une erreur lorsque le stockage interne est rempli : plus de place. Il n'a pas l'air de gérer automatiquement le transfert vers la carte SD, ce qui pourrait sembler logique… J'ai l'air de m'y prendre mal donc. Est-ce qu'il existe une solution avec les outils que j'ai utilisés (des paramètres à utiliser ou une configuration particulière) ou dois-je partir vers un outil dédié à cette tâche ?

  • # et le rsync est fait comment ?

    Posté par  . Évalué à 2.

    J'ai donc monté mes périphériques (avec un dossier Music à leur racine) et fait :
    unionfs-fuse /media/pointdemontage1=RW:/media/pointdemontage2=RW dossierfusion/Music

    ok

    Et j'ai utilisé rsync pour la copie. Mais ça ne fonctionne pas

    et ton rsync tu le fais comment ?

    que dit unionFS pour ce cas là (ecrire sur A, puis sur B)?
    ca marche si tu fais une simple copie d'un gros fichier par exemple ?

    • [^] # Re: et le rsync est fait comment ?

      Posté par  . Évalué à 1. Dernière modification le 17 décembre 2017 à 13:11.

      Merci de ta réponse.

      Alors concernant rsync, c'est un simple
      rsync -av --ignore-existing ~/music/ dossierfusion/Music

      Je n'ai pas l'impression que unionFS gère l'écriture sur plusieurs cibles, je n'ai trouvé aucune documentation à ce propos et la seule appréciation que j'ai trouvé précise ce fait : Topic superuser.com (même si je n'y vois aucune source pour corroborer).
      Mais le choix du dossier où écrire parait être le premier dossier en RW dans les paramètres de la commande unionfs-fuse : si je copie avec cp l'écriture se fait bien sur /media/pointdemontage1.

      J'ai donc pensé à inverser les deux paramètres pour mettre la carte SD (pointdemontage2) en premier :
      unionfs-fuse /media/pointdemontage2=RW:/media/pointdemontage1=RW dossierfusion/Music
      mais la même commande rsync continue à écrire sur le stockage interne (/media/pointdemontage1).
      Et si je copie avec cp, l'écriture se fait bien sur pointdemontage2. rsync et cp n'écrivent pas sur le même point de montage donc.

      • [^] # Re: et le rsync est fait comment ?

        Posté par  . Évalué à 2.

        j'imagine que ton cp se fait bien vers dossierfusion/Music/ ?

        si c'est le cas, alors oui, il y aurait une difference entre rsync et cp sur la maniere d'aller ecrire sur unionFS

        peut-etre simplement une histoire de place,
        le cp va copier TOUT le fichier,
        quand le rsync va copier des petits bouts du fichier

        • [^] # Re: et le rsync est fait comment ?

          Posté par  . Évalué à 1.

          Oui, le cp, c'est bien vers dossierfusion/Music/

          Du coup, j'ai testé différents paramètres pour que rsync copie le comportement de cp :
          - --whole-file
          - --preallocate
          - les deux en même temps

          rsync continue de copier sur le stockage interne…

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.