Forum Programmation.shell Rsync Problème avec effacement dans l'option --delete

Posté par . Licence CC by-sa.
Tags : aucun
1
18
août
2019

Bonjour à vous

Je n'arrive pas à supprimer les dossiers sur le répertoire de destination

mon dossier source est le dossier SpiderOak Hive que j'utilise pour la sauvegarde sécurisée à distance sur mon espace spiderOakOne !

REP_SOURCE3="/home/jean-luc/SpiderOak Hive/"
REP_DESTINATION3="/media/DD1_HomeKDE/jean-luc/SpiderOak Hive/"

rsync -a -r --verbose --stats --delete "$REP_SOURCE3" "$REP_DESTINATION3" 2> $backup3

Étant donné que dans le nom de ce répertoire il y a un espace j'ai été obligé de le mettre en guillemets pour que le shell, le prenne en charge ! Mais à priori la commande --delete de rsync ne supporte pas cela !!

Comment résoudre ce dilemme ?

  • # Plus de détails ?

    Posté par (page perso) . Évalué à 1 (+0/-0).

    Tu as des messages d'erreurs à nous indiquer ?

    Je ne vois pas du tout pourquoi rsync aurait des problèmes avec des noms de fichiers contenant des espaces. Exemple en local :

    $ mkdir foo "bar baz"
    $ for i in $(seq 0 9); do touch foo/$i; done
    $ rsync -av --delete foo "bar baz"
    sending incremental file list
    foo/
    foo/0
    foo/1
    foo/2
    foo/3
    foo/4
    foo/5
    foo/6
    foo/7
    foo/8
    foo/9
    
    sent 583 bytes  received 210 bytes  1,586.00 bytes/sec
    total size is 0  speedup is 0.00
    $ rm foo/{2,4,6,8}
    $ rsync -av --delete foo "bar baz"
    sending incremental file list
    deleting foo/8
    deleting foo/6
    deleting foo/4
    deleting foo/2
    foo/
    
    sent 146 bytes  received 52 bytes  396.00 bytes/sec
    total size is 0  speedup is 0.00
    

    Au passage : attention aux slashes en fin de nom de répertoire, ils sont significatifs pour rsync.

    Debian Consultant @ DEBAMAX

    • [^] # Re: Plus de détails ?

      Posté par . Évalué à 1 (+0/-0).

      Re
      Oui message d'erreur : _skipping file deletion

      Rsync n'efface pas sur la source mais uniquement avec ce nom de dossier SpiderOak Hive !

      Quand je lance d'autres scripts de sauvegarde sur des dossiers avec des noms sans espaces , Rsync efface correctement sur le répertoire destination ! C'est pour cela que j'en ai déduit cela ..

      J'ai écris dans mon premier message les commandes que je lance exactement comme dans mon script qui n'efface pas sur la destination…

      Je tourne en rond depuis pas mal de temps
      Je pense qu'il faut revoir les guillemets mais je ne sais pas comment faire !

      Si je ne mets pas les guillemets alors le nom du dossier pris en charge est la première partie du nom de dossier uniquement soit : SpiderOak et un dossier Hive est créé à côté .. mais en aucun cas la sauvegarde Rsync ne fonctionne !

      Si je mets les guillemets cela fonctionne avec tous mes sauvegardes comportant des noms de dossier sans espace !

      Avec l'espace du dossier "SpiderOak One" aucun effacement n'est réalisé

      • [^] # Re: Plus de détails ?

        Posté par . Évalué à 1 (+0/-0).

        En fait je pense que le souci se trouve avec Rsync + l'option --delete et un nom de fichier que l'on est obligé de mettre entre guillemet pour que le shell le prenne en considération dans son entièreté !

      • [^] # Re: Plus de détails ?

        Posté par . Évalué à 2 (+0/-0). Dernière modification le 18/08/19 à 19:34.

        Comme Cyril, je ne pense pas que le pb vienne des guillemets. Il les faut, tu les as mis, c'est tout.

        skipping file deletion

        Tu peux nous donner tous les messages stp ? En général il donne la raison, par exemple tu n'as pas le droit d'écrire sur la destination.

        Rsync n'efface pas sur la source

        Encore heureux ! :)

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Plus de détails ?

          Posté par . Évalué à 1 (+0/-0).

          voilà tout ce que j'ai !
          IO error encountered - skipping file deletion

          • [^] # Re: Plus de détails ?

            Posté par . Évalué à 1 (+0/-0).

            Pour tester j'ai renommé mes deux dossiers sources et destination et j'ai enlevé l'espace et modifié la commande en enlevant les guillemets

            Sur le dossier destination, les répertoire de rang 1, non présents sur la source ont été supprimés !
            Mais les répertoires plus profond et non présents sur la source n'ont pas été supprimés ! Problème de récursivité à modifier ?

            Donc la première cause est bien l'espace dans le nom et non un problème de droits d'accès par ex !

            Je suis obligé de renommé mes dossiers avec l'espace .. mon problème n'est donc pas résolu

          • [^] # Re: Plus de détails ?

            Posté par . Évalué à 2 (+0/-0).

            Ajoute l'option -vv pour que rsync te donne plus d'informations sur ce qui se passe et les erreurs rencontrées.

      • [^] # Re: Plus de détails ?

        Posté par (page perso) . Évalué à 1 (+0/-0).

        Un problème de droits sur un ou plusieurs fichiers/répertoires ? Ce serait plutôt simple à corriger, plutôt qu'un éventuel de système de fichiers/disques… Les « I/O errors », ça fait toujours un peu peur…

        Voir aussi :

        --ignore-errors
                Tells --delete to go ahead and delete files even when there are I/O errors.
        

        Debian Consultant @ DEBAMAX

        • [^] # Re: Plus de détails ?

          Posté par . Évalué à 1 (+0/-0).

          en faisant ceci : rsync -av --recursive --verbose --stats --delete --force "$REP_SOURCE3" "$REP_DESTINATION3" 2> $backup3
          Il n'y a plus d'erreur !

          Oui effectivement les erreurs I/O me font peur aussi et j'avais donc tester en parallèle sur un HDD en usb et il y avait le même soucis et là aussi avec cette commande plus d'erreur

          Par contre à force de faire plein d'essais, en renommant même le dossier source et destination sans l'espace, j'ai créé pour tester un dossier sur la destination au niveau du rang 1, et, je me suis aperçu que la suppression de dossier se faisait mais uniquement sur les dossiers du premier niveau. Plus profond en récursivité, la suppression n'est pas effective.

          …. ?

          • [^] # Re: Plus de détails ?

            Posté par . Évalué à 2 (+1/-0).

            Solution trouvée

            A force de chercher sans comprendre….

            Sur un dossier de 80 Go , un petit fichier de 30 octets avait des droits root => ce simple fichier a donc empêché l'option --delete de rsync de fonctionner correctement

            Merci à vous tous de votre aide

            A plus jibi

Envoyer un commentaire

Suivre le flux des commentaires

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