rsync et ses backups

[Bernd]

Hi,

J'effectue régulièrement des backups de répertoires avec le rapide et
très fiable rsync en ligne de commande.
J'utilise la formule 'rsync --ignore-errors --delete-before -Haurovl
--stats ...'
qui permet d'effacer dans la cible les fichiers présents dans la source
mais pas dans la cible et d'obtenir un miroir exact et à jour de la
source dans la cible.
Tout marche bien sauf...
...sauf iTunes.
J'ai systématiquement une recopie complète de tous les fichiers de
iTunes même ceux qui n'ont jamais été ouverts ni ajoutés ni... rien !
Donc perte de temps et de ressources de la synchro.

Je suppose que c'est une question de date ou autre que iTunes ajoute
sans arrêt et systématiquement - ce qui tromperait rsync.
Connaissez-vous ce dysfonctionnement et voyez vous comment y remédier ?

A+
--
Romer

[pehache]

As-tu vérifié les dates des fichiers en question juste avant le rsync,
pour voir si c'est normal ou pas que rsync les recopie ?

Normalement si tu fais deux rsync successifs avec iTunes qui reste fermé
pendant tout ce temps, le second rsync n'a aucune raison de refaire une
copie.

J'ai néanmoins déjà constaté ce comportement de rsync avec des fichiers
qui ont des caractères "spéciaux" (accentués et autres) dans leurs noms.
C'est un problème d'encodage différent des caractères entre le système
de fichiers source et le système de fichiers cible, qui bizarremment
empêche rsync de "voir" que le fichier cible n'a pas besoin d'être mis à
jour.


--
"...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
même sens que les tiennes.", ST sur fr.bio.medecine

[Bernd]

pehache <peha...@gmail.com> wrote:

> As-tu vérifié les dates des fichiers en question juste avant le rsync,
> pour voir si c'est normal ou pas que rsync les recopie ?

Je viens de faire une syncro - pareil, il recopie 711 fichiers et en
efface autant

Je refais le même backup 5s plus tard -> idem - il efface et recopie des
centaines de fichiers...

> J'ai néanmoins déjà constaté ce comportement de rsync avec des fichiers
> qui ont des caractères "spéciaux" (accentués et autres) dans leurs noms.
> C'est un problème d'encodage différent des caractères entre le système
> de fichiers source et le système de fichiers cible, qui bizarremment
> empêche rsync de "voir" que le fichier cible n'a pas besoin d'être mis à
> jour.

Oui ces fichier musicaux ont des espaces dans le nom, des slashs, des
accents, etc.
L'ennui est qu'ils sont tellement nombreux que je ne peux pas modifier
tout cela à la main.

A+
--
Romer

[Bernd]

MV <m...@invalid.orange.fr> wrote:

> Bernd <ro...@vat.com> n'a pas hésité à écrire :

>
> > permet d'effacer dans la cible les fichiers présents dans la source
> > mais pas dans la cible
>

> ???
> Ça efface des fichiers dans la cible qui n'y sont pas ?
>
> Cordialement

J'ai dû mal m'exprimer avec ses négations.

Si un fichier est absent dans la source mais encore présent dans la
cible, il sera effacé dans la cible - il faut que la cible soit
identique à la source apeès le backup : pas un fichier de plus ni de
moins.
C'est du moins ce que je souhaite comme strtégie - on peut faire
différemment.

A+
--
Romer

[pehache]

Le 01/05/2019 à 11:09, Bernd a écrit :
>
>> J'ai néanmoins déjà constaté ce comportement de rsync avec des fichiers
>> qui ont des caractères "spéciaux" (accentués et autres) dans leurs noms.
>> C'est un problème d'encodage différent des caractères entre le système
>> de fichiers source et le système de fichiers cible, qui bizarremment
>> empêche rsync de "voir" que le fichier cible n'a pas besoin d'être mis à
>> jour.
>
> Oui ces fichier musicaux ont des espaces dans le nom, des slashs, des
> accents, etc.

OK, c'est donc probablement l'explication ici aussi.

> L'ennui est qu'ils sont tellement nombreux que je ne peux pas modifier
> tout cela à la main.

La question est : comment sont formatés les disques source et cible ? La
source je suppose c'est du APFS ou HFS+, et la cible ?

[Bernd]

pehache <peha...@gmail.com> wrote:

> > L'ennui est qu'ils sont tellement nombreux que je ne peux pas modifier
> > tout cela à la main.
>
> La question est : comment sont formatés les disques source et cible ? La
> source je suppose c'est du APFS ou HFS+, et la cible ?

C'est spécial.
La source est un SSD externe Crucial dans son boitier - formaté APFS.
La cible est une barrette SSD Transcend dans son boitier - formaté Mac
OS etendu.
Même si cette config peut sembler bizarre et criticable, la question
demeure : Pourquoi seul iTunes et ses milliers de fichiers dysfonctionne
à ce point alors que tout le reste fonctionne nickel avec des Gigas de
données transférés ?

A+
--
Romer

[pehache]

Le 01/05/2019 à 20:20, Bernd a écrit :
> pehache <peha...@gmail.com> wrote:
>
>>> L'ennui est qu'ils sont tellement nombreux que je ne peux pas modifier
>>> tout cela à la main.
>>
>> La question est : comment sont formatés les disques source et cible ? La
>> source je suppose c'est du APFS ou HFS+, et la cible ?
>
> C'est spécial.
> La source est un SSD externe Crucial dans son boitier - formaté APFS.
> La cible est une barrette SSD Transcend dans son boitier - formaté Mac
> OS etendu.
> Même si cette config peut sembler bizarre et criticable,

Oui, et je me tâte d'ailleurs pour te dénoncer à la police des bons
usages des périphériques de stockage...

> la question
> demeure : Pourquoi seul iTunes et ses milliers de fichiers dysfonctionne
> à ce point alors que tout le reste fonctionne nickel avec des Gigas de
> données transférés ?

As-tu des fichiers avec des noms accentués ailleurs ?

[pehache]

Le 01/05/2019 à 20:20, Bernd a écrit :

> pehache <peha...@gmail.com> wrote:
>
>>> L'ennui est qu'ils sont tellement nombreux que je ne peux pas modifier
>>> tout cela à la main.
>>
>> La question est : comment sont formatés les disques source et cible ? La
>> source je suppose c'est du APFS ou HFS+, et la cible ?
>
> C'est spécial.
> La source est un SSD externe Crucial dans son boitier - formaté APFS.
> La cible est une barrette SSD Transcend dans son boitier - formaté Mac
> OS etendu.

J'ai oublié le principal : il faudrait vérifier quel est l'encodage par
défaut des caractères de noms de fichiers en APFS et en HFS.

[pehache]

Le 01/05/2019 à 21:05, Le Moustique a écrit :
> Le 01/05/2019 à 20:20, Bernd a écrit :

>> Même si cette config peut sembler bizarre et criticable, la question
>> demeure : Pourquoi seul iTunes et ses milliers de fichiers dysfonctionne
>> à ce point alors que tout le reste fonctionne nickel avec des Gigas de
>> données transférés ?
>

> A mon avis, c'est parce que par défaut iTunes et ses fichiers musicaux
> sont considérés comme une appli, c'est à dire un "fichier" (dossier)
> unique.

Non, dans aucun cas. Même si on laisse iTunes tout gérer à sa sauce,
chaque morceau est dans un fichier .m4a individuel.

[Bernd]

pehache <peha...@gmail.com> wrote:

> > la question
> > demeure : Pourquoi seul iTunes et ses milliers de fichiers dysfonctionne
> > à ce point alors que tout le reste fonctionne nickel avec des Gigas de
> > données transférés ?
>
> As-tu des fichiers avec des noms accentués ailleurs ?

Sur des milliers de fichiers et des Go de données, je ne sais pas
précisément mais je pense sûrement que oui (par probabilité)
Parmi ces nombreux fichiers, pas un seul n'est mis à jour s'il n'a pas
été modifié d'une façon ou une autre.

A+
--
Romer

[pehache]

Le 01/05/2019 à 21:17, Bernd a écrit :
> pehache <peha...@gmail.com> wrote:
>
>>> la question
>>> demeure : Pourquoi seul iTunes et ses milliers de fichiers dysfonctionne
>>> à ce point alors que tout le reste fonctionne nickel avec des Gigas de
>>> données transférés ?
>>
>> As-tu des fichiers avec des noms accentués ailleurs ?
>
> Sur des milliers de fichiers et des Go de données, je ne sais pas
> précisément mais je pense sûrement que oui (par probabilité)

Bah, ce n'est pas évident du tout...

Fais le test en créant un fichier avec des accents pour voir ce que
rsync en fait.

[pehache]

Le 01/05/2019 à 21:45, Le Moustique a écrit :

> Le 01/05/2019 à 21:12, pehache a écrit :
>>> A mon avis, c'est parce que par défaut iTunes et ses fichiers
>>> musicaux sont considérés comme une appli, c'est à dire un "fichier"
>>> (dossier) unique.
>>
>> Non, dans aucun cas. Même si on laisse iTunes tout gérer à sa sauce,
>> chaque morceau est dans un fichier .m4a individuel.
>>

> Je ne dis pas le contraire (mais ça peut être un fichier .mp3), sauf que
> ledit fichier est inclus dans la bibliothèque iTunes, que rsync
> considère peut-être à défaut comme un fichier unique.

Ben non, si le fichier est individuel il n'est par définition pas inclus
dans autre chose. La bibliothèque iTunes c'est en pratique un fichier
XML qui contient les métadonnées iTunes et les chemins vers les fichiers
des morceaux.

[Bernd]

MV <m...@invalid.orange.fr> wrote:

> pehache <peha...@gmail.com> n'a pas hésité à écrire :

>
> > Fais le test en créant un fichier avec des accents pour voir ce que
> > rsync en fait.

Pour l'instant je pars en voyage - malheureusement j'arrête là
discussion et essais. Je verrai sur place si Free fonctionne avec les
forums.

> Je suis actuellement confronté à ce problème de fichier dont le nom
> comporte un accent avec la commande "cat liste | grep 'Durée'"
> Si je tape 'Durée' à la main, ça foire mais si je copie/colle 'Durée'
> depuis la liste ou directement depuis le Finder en sélectionnant le nom
> du fichier nommé 'Durée', ça fonctionne !
> Le Terminal gère bizarrement les caractères accentués.

Idem surtout pour la recherche de fichiers qui comportent accents,
espaces et même slash.
Chercher cela est fastidieux : 'Bébés et gâteaux [1]' par ex.
Il faut mettre des slashs partout pour échapper les caractères spéciaux
mais ça ne marche pas toujours.

A+
--
Romer

[pehache]

Le 02/05/2019 à 08:58, Bernd a écrit :
> MV <m...@invalid.orange.fr> wrote:
>
>> pehache <peha...@gmail.com> n'a pas hésité à écrire :
>>
>> > Fais le test en créant un fichier avec des accents pour voir ce que
>> > rsync en fait.
>
> Pour l'instant je pars en voyage - malheureusement j'arrête là
> discussion et essais. Je verrai sur place si Free fonctionne avec les
> forums.
>
>> Je suis actuellement confronté à ce problème de fichier dont le nom
>> comporte un accent avec la commande "cat liste | grep 'Durée'"
>> Si je tape 'Durée' à la main, ça foire mais si je copie/colle 'Durée'
>> depuis la liste ou directement depuis le Finder en sélectionnant le nom
>> du fichier nommé 'Durée', ça fonctionne !
>> Le Terminal gère bizarrement les caractères accentués.
>
> Idem surtout pour la recherche de fichiers qui comportent accents,
> espaces et même slash.

L'espace est le séparateur naturel dans les shells unix, et le slash est
le séparateur unix pour les chemins des fichiers. Utiliser un slash ("/")
dans un nom de fichier est possible sous macOS, mais je le déconseille
fortement (tout comme les caractères ":" et "\" qui ont des significations
différentes entre macOS, Windows, et unix)

> Chercher cela est fastidieux : 'Bébés et gâteaux [1]' par ex.
> Il faut mettre des slashs

backslashs, pas slashs

> partout pour échapper les caractères spéciaux

On peut aussi mettre le nom complet entre quotes (simples ou doubles) pour
éviter d'échapper tous les caractères spéciaux.

> mais ça ne marche pas toujours.

Ce qui est mal foutu c'est que l'encodage des caractères n'a pas l'air
d'être le même entre le Finder et le Terminal.

[SbM]

pehache <peha...@gmail.com> wrote:

> Le 01/05/2019 à 21:45, Le Moustique a écrit :
> > Le 01/05/2019 à 21:12, pehache a écrit :
> >>> A mon avis, c'est parce que par défaut iTunes et ses fichiers
> >>> musicaux sont considérés comme une appli, c'est à dire un "fichier"
> >>> (dossier) unique.
> >>
> >> Non, dans aucun cas. Même si on laisse iTunes tout gérer à sa sauce,
> >> chaque morceau est dans un fichier .m4a individuel.
> >>
> > Je ne dis pas le contraire (mais ça peut être un fichier .mp3), sauf que
> > ledit fichier est inclus dans la bibliothèque iTunes, que rsync
> > considère peut-être à défaut comme un fichier unique.
>
> Ben non, si le fichier est individuel il n'est par définition pas inclus
> dans autre chose. La bibliothèque iTunes c'est en pratique un fichier
> XML qui contient les métadonnées iTunes et les chemins vers les fichiers
> des morceaux.

+1. Le Moustique fait fausse route, ou confond avec feu iPhoto.

--
[SbM]
"If the French were really intelligent, they'd speak English" (W. Sheed)

[Manfred]

MV <m...@invalid.orange.fr> wrote:

> pehache <peha...@gmail.com> wrote:
>
>> Ce qui est mal foutu c'est que l'encodage des caractères n'a pas l'air
>> d'être le même entre le Finder et le Terminal.
>
>
>

> Cordialement

??

--
Manfred

[Manfred]

MV <m...@invalid.orange.fr> wrote:
> Manfred <der...@wanamoo.fr> n'a pas hésité à écrire :
>
>> ??
>
> Je me demande bien où est passée la réponse que j'avais rédigée !
>
> Cordialement

Je me doutais bien que cette réponse vide, c’était « à l’insu de ton plein
gré » ;-)

--
Manfred

[pehache]

Le 01/05/2019 à 10:09, Bernd a écrit :

Si tu lis le fil que j'ai ouvert "montage NFS, encodage des noms de
fichiers, et rsync", il est probable que la même solution s'applique à
ton problème :

Vérifier ta version de rsync ("rsync --version") : si inférieure à à la
version 3.x, il faut en installer une plus récente pour avoir l'option
"--iconv"

Ajouter l'option "--iconv=utf-8-mac,utf-8-mac"

[Bernd]

pehache <peha...@gmail.com> wrote:

> > Je suppose que c'est une question de date ou autre que iTunes ajoute
> > sans arrêt et systématiquement - ce qui tromperait rsync.
> > Connaissez-vous ce dysfonctionnement et voyez vous comment y remédier ?
>
> Si tu lis le fil que j'ai ouvert "montage NFS, encodage des noms de
> fichiers, et rsync", il est probable que la même solution s'applique à
> ton problème :
>
> Vérifier ta version de rsync ("rsync --version") : si inférieure à à la
> version 3.x, il faut en installer une plus récente pour avoir l'option
> "--iconv"
>
> Ajouter l'option "--iconv=utf-8-mac,utf-8-mac"

Merci - J'ai la 3.1.3 donc --iconv devrait marcher.
Effectivement, apparemment ça le fait.
Merci du tuyau.

A+
--
Romer

[pehache]

Cool !