Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.os.unix > #7913 > unrolled thread

rsync en milieu hétérogène

Back to article view | Back to fr.comp.os.unix

Contents

  rsync en milieu hétérogène Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-03-17 00:06 +0100
    Re: rsync en milieu hétérogène Nicolas George <nicolas$george@salle-s.org> - 2022-03-16 23:18 +0000
      Re: rsync en milieu hétérogène Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2022-03-17 00:53 +0100
        Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-17 11:00 +0000
          Re: rsync en milieu hétérogène Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-03-17 15:59 +0100
            Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-17 16:29 +0000
              Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-17 21:52 +0100
              Re: rsync en milieu hétérogène Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-03-19 17:28 +0100
                Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-20 16:20 +0100
                  Re: rsync en milieu hétérogène Nicolas George <nicolas$george@salle-s.org> - 2022-03-20 15:40 +0000
                    Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-21 08:46 +0100
                Re: rsync en milieu hétérogène Nicolas George <nicolas$george@salle-s.org> - 2022-03-20 15:42 +0000
                  Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-21 09:01 +0100
                    Re: rsync en milieu hétérogène Nicolas George <nicolas$george@salle-s.org> - 2022-03-21 12:30 +0000
                      Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-21 13:26 +0000
      Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-17 10:56 +0000
        Re: rsync en milieu hétérogène Nicolas George <nicolas$george@salle-s.org> - 2022-03-17 13:47 +0000
          Re: rsync en milieu hétérogène Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-03-17 15:15 +0100
          Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-17 15:16 +0000
    Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-17 10:54 +0000
      Re: rsync en milieu hétérogène Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-03-17 15:12 +0100
        Re: rsync en milieu hétérogène pehache <pehache.7@gmail.com> - 2022-03-17 14:36 +0000

Page 1 of 2  [1] 2  Next page →

#7913 — rsync en milieu hétérogène

bonjour :-)


j'ai un pb avec rsync :

l'option '--delete-after' m'efface tous les fichiers dont le nom 
contient des caractères non-ascii, aussitôt après les avoir copiés.


il est probable que le pb soit lié au fait que rsync soit utilisé en 
milieu hétérogène (mais je pensais que rsync était rodé à ce genre de 
cas de figure un peu biscornu) :

systèmes de fichiers :
Source : par défaut sous Ubuntu, je crois bien que c'est ext4.
Destination : par défaut sous Mac OS X, HFS+.

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [next] | [standalone]

#7914

Thomas , dans le message
<fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, a écrit :
> Destination : par défaut sous Mac OS X, HFS+.

Vérifie si les caractères accentués ont été mis sous une forme canonique
différente. Je crois me rappeler qu'Apple a décidé d'utiliser une forme
décomposée, parce que faire comme tout le monde ça leur arracherait la
gueule et pour embêter gratuitement les gens qui voudraient utiliser autre
chose que des Appleries.

[toc] | [prev] | [next] | [standalone]

#7915

Nicolas George <nicolas$george@salle-s.org> writes:

> Thomas , dans le message
> <fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, a écrit :
>> Destination : par défaut sous Mac OS X, HFS+.
>
> Vérifie si les caractères accentués ont été mis sous une forme canonique
> différente. Je crois me rappeler qu'Apple a décidé d'utiliser une forme
> décomposée, parce que faire comme tout le monde ça leur arracherait la
> gueule et pour embêter gratuitement les gens qui voudraient utiliser autre
> chose que des Appleries.

Dans mon souvenir, HFS+ n'est même pas "case-sensitive" (par défaut)...

Bon, toujours est-il que rsync a une option --iconv qui semble régler le
problème :

https://odd.blog/2020/10/06/rsync-between-mac-and-linux/

suggère --iconv=utf-8,utf-8-mac ("utf-8-mac" ? mdr)

-- Alain.

P/S: Pour mémoire : "[HFS+ is] complete and utter crap." (Linus Torvalds)

[toc] | [prev] | [next] | [standalone]

#7920

Le 17/03/2022 à 00:53, Alain Ketterlin a écrit :
> Nicolas George <nicolas$george@salle-s.org> writes:
> 
>> Thomas , dans le message
>> <fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, a écrit :
>>> Destination : par défaut sous Mac OS X, HFS+.
>>
>> Vérifie si les caractères accentués ont été mis sous une forme canonique
>> différente. Je crois me rappeler qu'Apple a décidé d'utiliser une forme
>> décomposée, parce que faire comme tout le monde ça leur arracherait la
>> gueule et pour embêter gratuitement les gens qui voudraient utiliser autre
>> chose que des Appleries.
> 
> Dans mon souvenir, HFS+ n'est même pas "case-sensitive" (par défaut)...
> 
> Bon, toujours est-il que rsync a une option --iconv qui semble régler le
> problème :
> 
> https://odd.blog/2020/10/06/rsync-between-mac-and-linux/
> 
> suggère --iconv=utf-8,utf-8-mac ("utf-8-mac" ? mdr)

J'ai eu un cas similaire à gérer, et ce qui a marché pour moi c'était 
--iconv=utf-8-mac,utf-8-mac

mettre un utf-8 tout court ne changeait rien, et je n'ai pas compris ce 
que ça convertissait en mettant deux fois utf-8-mac !


> P/S: Pour mémoire : "[HFS+ is] complete and utter crap." (Linus Torvalds)

C'est pour ça qu'il a été remplacé il y a plusieurs années par APFS

[toc] | [prev] | [next] | [standalone]

#7926

In article <ZJudvuYECwR-EQAYQmdfUcm7wFU@jntp>,
 pehache <pehache.7@gmail.com> wrote:

> Le 17/03/2022 à 00:53, Alain Ketterlin a écrit :
> > Nicolas George <nicolas$george@salle-s.org> writes:
> > 
> >> Thomas , dans le message
> >> <fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, a écrit :
> >>> Destination : par défaut sous Mac OS X, HFS+.
> >>
> >> Vérifie si les caractères accentués ont été mis sous une forme canonique
> >> différente. Je crois me rappeler qu'Apple a décidé d'utiliser une forme
> >> décomposée,

je ne comprend pas une chose :
on a probablement besoin de faire cette conversion pour que les accents 
s'affichent correctement sur l'autre machine,
mais puisque ça reste des chaines utf-8 valides, pourquoi est ce que ça 
fait ces drôles d'erreurs ? (ça n'est pas une erreur à l'écriture du 
fichier, seulement lors d'une certaine comparaison !)

> >> parce que faire comme tout le monde ça leur arracherait la
> >> gueule et pour embêter gratuitement les gens qui voudraient utiliser autre
> >> chose que des Appleries.
> > 
> > Dans mon souvenir, HFS+ n'est même pas "case-sensitive" (par défaut)...

en ada, on appelle ça "case-preserving", cad que lui il se souvient de 
la case que t'as utilisé en créant le fichier, mais si toi tu ne t'en 
souviens pas il le retrouve.
y compris si tu crée un nouveau fichier dont seule la case est différente
(mais ça a l'avantage d'être compatible avec les FS "case-insensitive", 
quand on crée dessus)

> > 
> > Bon, toujours est-il que rsync a une option --iconv qui semble régler le
> > problème :
> > 
> > https://odd.blog/2020/10/06/rsync-between-mac-and-linux/
> > 
> > suggère --iconv=utf-8,utf-8-mac ("utf-8-mac" ? mdr)

rsync: on remote machine: --iconv=utf-8-mac: unknown option
rsync error: syntax or usage error (code 1) at 
/SourceCache/rsync/rsync-40/rsync/main.c(1333) [server=2.6.9]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) 
[sender=3.1.1]


> 
> J'ai eu un cas similaire à gérer, et ce qui a marché pour moi c'était 
> --iconv=utf-8-mac,utf-8-mac
> 
> mettre un utf-8 tout court ne changeait rien, et je n'ai pas compris ce 
> que ça convertissait en mettant deux fois utf-8-mac !

iconv_open("UTF-8", "utf-8-mac") failed
rsync error: requested action not supported (code 4) at rsync.c(122) 
[sender=3.1.1]
rsync error: received SIGUSR1 (code 19) at main.c(1434) [sender=3.1.1]


bon, ça a l'air bien compliqué avec ces vieilles machines ...

est ce que qqn a une autre idée ?
genre, remplacer les caractères non-ascii par %, pour que au moins le 
rsync serveur n'ait rien à gérer ?



> 
> 
> > P/S: Pour mémoire : "[HFS+ is] complete and utter crap." (Linus Torvalds)
> 
> C'est pour ça qu'il a été remplacé il y a plusieurs années par APFS

c'est mieux conçu ?

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [prev] | [next] | [standalone]

#7929

Le 17/03/2022 à 15:59, Thomas a écrit :
> 
> je ne comprend pas une chose :
> on a probablement besoin de faire cette conversion pour que les accents 
> s'affichent correctement sur l'autre machine,
> mais puisque ça reste des chaines utf-8 valides, pourquoi est ce que ça 
> fait ces drôles d'erreurs ? 

rsync compare les noms de fichiers, et pour se faire il faut que 
l'encodage soit le même.


>> > Bon, toujours est-il que rsync a une option --iconv qui semble régler le
>> > problème :
>> > 
>> > https://odd.blog/2020/10/06/rsync-between-mac-and-linux/
>> > 
>> > suggère --iconv=utf-8,utf-8-mac ("utf-8-mac" ? mdr)
> 
> rsync: on remote machine: --iconv=utf-8-mac: unknown option

Mmhhhh bizarre... 


>> J'ai eu un cas similaire à gérer, et ce qui a marché pour moi c'était 
>> --iconv=utf-8-mac,utf-8-mac
>> 
>> mettre un utf-8 tout court ne changeait rien, et je n'ai pas compris ce 
>> que ça convertissait en mettant deux fois utf-8-mac !
> 
> iconv_open("UTF-8", "utf-8-mac") failed

En fait c'est logique, tu lui dis que les noms locaux sont en utf8-mac, ce 
qui ne doit pas être possible sur du extfs

Il faudrait que je retrouve le contexte de mon double utf8-mac !

> bon, ça a l'air bien compliqué avec ces vieilles machines ...
> 
> est ce que qqn a une autre idée ?

Faire le rsync depuis le Mac plutôt que depuis le PC linux ?

> genre, remplacer les caractères non-ascii par %, pour que au moins le 
> rsync serveur n'ait rien à gérer ?

Quel rsync serveur ? A priori il n'y en a pas là...


>> > P/S: Pour mémoire : "[HFS+ is] complete and utter crap." (Linus Torvalds)
>> 
>> C'est pour ça qu'il a été remplacé il y a plusieurs années par APFS
> 
> c'est mieux conçu ?

En principe oui, c'était le but :)

HFS+ était une surcouche bricolée par dessus HFS, qui datait du début 
des années 80. APFS a été concçu from scratch.

[toc] | [prev] | [next] | [standalone]

#7931

Le 17/03/2022 à 17:29, pehache a écrit :
> 
>>> J'ai eu un cas similaire à gérer, et ce qui a marché pour moi c'était 
>>> --iconv=utf-8-mac,utf-8-mac
>>>
>>> mettre un utf-8 tout court ne changeait rien, et je n'ai pas compris 
>>> ce que ça convertissait en mettant deux fois utf-8-mac !
>>
>> iconv_open("UTF-8", "utf-8-mac") failed
> 
> En fait c'est logique, tu lui dis que les noms locaux sont en utf8-mac, 
> ce qui ne doit pas être possible sur du extfs
> 
> Il faudrait que je retrouve le contexte de mon double utf8-mac !


Alors c'est un rsync qui tourne sur le Mac, et qui fait ça (j'élague les 
options) :

rsync --archive --delete /mnt/nfs/TOTO/* /Volumes/TITI

TOTO est un montage NFS sur un NAS Synology (variante BSD), avec cette 
ligne dans /etc/auto_nfs :
TOTO     -fstype=nfs,noatime,rw,nfc nfs://xxxxx:/volume1/TOTO

L'option nfc est nécessaire pour dire que sur le disque distant les noms 
de fichiers sont sous forme NFC, et je suppose qu'ils sont présentés 
sous forme NFD à macOS.

/Volumes/TITI est un disque externe formaté en exfat.

Sans iconv du tout, la commande rsync ci-dessus a le même défaut que ce 
que tu as soulevé : les fichiers avec des caractères spéciaux dans le 
nom sont systématiquement effacés et recopiés. Pour que ça se comporte 
comme attendu je dois mettre :

--iconv=utf-8,utf-8-mac
ou
--iconv=utf-8-mac,utf-8-mac

1) je ne comprends pas pourquoi ça marche pareil en mettant utf-8 ou 
utf-8-mac en première position.

2) le man dit que c'est --iconv=LOCAL,REMOTE ... sauf que dans le cas 
d'un rsync entre des disques locaux et/ou montés (pas de ssh ou démon 
rsync, donc pas de notion de machine distante), ce qui est de l'ordre du 
LOCAL et du REMOTE n'est pas clair du tout...

3) je comprends encore moins pourquoi ça marche alors que l'encodage sur 
exfat est de l'UTF-16 et pas de l'UTF-8 (ça je viens de le percuter en 
écrivant ce message !)

Bref...

-- 
"...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
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

[toc] | [prev] | [next] | [standalone]

#7934

In article <ia0VOW1Gntb-rQvLlTV4cJ5mSrk@jntp>,
 pehache <pehache.7@gmail.com> wrote:

> Le 17/03/2022 à 15:59, Thomas a écrit :
> > 
> > je ne comprend pas une chose :
> > on a probablement besoin de faire cette conversion pour que les accents 
> > s'affichent correctement sur l'autre machine,
> > mais puisque ça reste des chaines utf-8 valides, pourquoi est ce que ça 
> > fait ces drôles d'erreurs ? 
> 
> rsync compare les noms de fichiers, et pour se faire il faut que 
> l'encodage soit le même.

c'était pas logique si on considérait que les 2 étaient du utf-8,
mais je pense que j'ai compris ...

> 
> 
> >> > Bon, toujours est-il que rsync a une option --iconv qui semble régler le
> >> > problème :
> >> > 
> >> > https://odd.blog/2020/10/06/rsync-between-mac-and-linux/
> >> > 
> >> > suggère --iconv=utf-8,utf-8-mac ("utf-8-mac" ? mdr)
> > 
> > rsync: on remote machine: --iconv=utf-8-mac: unknown option
> 
> Mmhhhh bizarre... 

j'ai vérifié le man rsync du mac : il ne connait pas l'option --iconv
(tu devrais pouvoir le vérifier avec le n° de version qu'il donne).

> 
> 
> >> J'ai eu un cas similaire à gérer, et ce qui a marché pour moi c'était 
> >> --iconv=utf-8-mac,utf-8-mac
> >> 
> >> mettre un utf-8 tout court ne changeait rien, et je n'ai pas compris ce 
> >> que ça convertissait en mettant deux fois utf-8-mac !
> > 
> > iconv_open("UTF-8", "utf-8-mac") failed
> 
> En fait c'est logique, tu lui dis que les noms locaux sont en utf8-mac, ce 
> qui ne doit pas être possible sur du extfs

en fait c'est possible, mais là ça n'est pas le cas, donc de toutes 
façons ça n'était pas bon.


> > bon, ça a l'air bien compliqué avec ces vieilles machines ...
> > 
> > est ce que qqn a une autre idée ?
> 
> Faire le rsync depuis le Mac plutôt que depuis le PC linux ?

ça ne marche pas.


après avoir fait différentes manipulations avec un petit répertoire 
contenant des noms de fichier avec accents, je pense que j'ai compris 
l'origine du pb :

en fait, cette #### de HFS+ est "case-preserving" pour ce qui concerne 
purement la case, mais se comporte comme un "case-insensitive" avec les 
accents !
cad que quand on écrit un accent de la manière qui ne lui plait pas, il 
le modifie à la manière qui lui plait, pour l'enregistrer et le 
resservir plus tard ...

alors que ext4 ne fait pas ça.

(pour le vérifier complètement, il faudrait que je puisse voir à 
l'intérieur des noms de fichiers, un simple ls ne le permet pas 
puisqu'il affiche les accents correctement.)


la conséquence, c'est que ce pb de comparaison de noms de fichiers est 
posé à chaque fois qu'on déplace des fichiers de ext4 vers HFS+, mais 
pas quand on les déplace de HFS+ vers ext4.

peu importe depuis quelle machine on pilote ça,
et ça explique pourquoi je n'ai jamais eu de pb depuis mon mac jusqu'à 
maintenant
(en fait j'utilise des machines virtuelles avec ext4, mais je n'ai 
jamais mis d'accents dessus, ça n'est pas un usage "domestique").


> 
> > genre, remplacer les caractères non-ascii par %, pour que au moins le 
> > rsync serveur n'ait rien à gérer ?
> 
> Quel rsync serveur ? A priori il n'y en a pas là...

ce que je comprend c'est que :
à travers ssh, il ne fait pas du sftp ou du sshfs,
mais il lance un rsync distant qu'il utilise comme un serveur, même s'il 
le referme après l'opération.

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [prev] | [next] | [standalone]

#7937

Le 19/03/2022 à 17:28, Thomas a écrit :

>>
>>>>> Bon, toujours est-il que rsync a une option --iconv qui semble régler le
>>>>> problème :
>>>>>
>>>>> https://odd.blog/2020/10/06/rsync-between-mac-and-linux/
>>>>>
>>>>> suggère --iconv=utf-8,utf-8-mac ("utf-8-mac" ? mdr)
>>>
>>> rsync: on remote machine: --iconv=utf-8-mac: unknown option
>>
>> Mmhhhh bizarre...
> 
> j'ai vérifié le man rsync du mac : il ne connait pas l'option --iconv
> (tu devrais pouvoir le vérifier avec le n° de version qu'il donne).

En effet sur mon macOS (10.12, donc qui date de quelques années) c'est 
une version de rsync relativement ancienne qui est dispo, et j'avais 
oublié que j'avais installé le rsync de MacPorts, qui lui supporte l'option.

> 
> après avoir fait différentes manipulations avec un petit répertoire
> contenant des noms de fichier avec accents, je pense que j'ai compris
> l'origine du pb :
> 
> en fait, cette #### de HFS+ est "case-preserving" pour ce qui concerne
> purement la case, mais se comporte comme un "case-insensitive" avec les
> accents !
> cad que quand on écrit un accent de la manière qui ne lui plait pas, il
> le modifie à la manière qui lui plait, pour l'enregistrer et le
> resservir plus tard ...

??

>>
>> Quel rsync serveur ? A priori il n'y en a pas là...
> 
> ce que je comprend c'est que :
> à travers ssh, il ne fait pas du sftp ou du sshfs,
> mais il lance un rsync distant qu'il utilise comme un serveur, même s'il
> le referme après l'opération.

Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner 
même en l'absence d'un rsync disponible sur la machine distante.


-- 
"...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
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

[toc] | [prev] | [next] | [standalone]

#7938

pehache , dans le message <j9ov2hF20dpU1@mid.individual.net>, a écrit :
> Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner 
> même en l'absence d'un rsync disponible sur la machine distante.

???

[toc] | [prev] | [next] | [standalone]

#7942

Le 20/03/2022 à 16:40, Nicolas George a écrit :
> pehache , dans le message <j9ov2hF20dpU1@mid.individual.net>, a écrit :
>> Ca me parait bizarre, parce qu'un rsync via ssh est censé fonctionner
>> même en l'absence d'un rsync disponible sur la machine distante.
> 
> ???

J'avais lu ça je ne sais plus où, mais effet c'est faux.


-- 
"...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
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

[toc] | [prev] | [next] | [standalone]

#7939

Thomas , dans le message
<fantome.forums.tDeContes-5BFFE9.17283819032022@news.free.fr>, a écrit :
> en fait, cette #### de HFS+ est "case-preserving" pour ce qui concerne 
> purement la case, mais se comporte comme un "case-insensitive" avec les 
> accents !
> cad que quand on écrit un accent de la manière qui ne lui plait pas, il 
> le modifie à la manière qui lui plait, pour l'enregistrer et le 
> resservir plus tard ...

Exactement. « Gloire à Apple ! Merci notre maître de nous préserver de la
tentation d'aller voir ailleurs si l'herbe est plus grasse. »

[toc] | [prev] | [next] | [standalone]

#7943

Le 20/03/2022 à 16:42, Nicolas George a écrit :
> Thomas , dans le message
> <fantome.forums.tDeContes-5BFFE9.17283819032022@news.free.fr>, a écrit :
>> en fait, cette #### de HFS+ est "case-preserving" pour ce qui concerne
>> purement la case, mais se comporte comme un "case-insensitive" avec les
>> accents !
>> cad que quand on écrit un accent de la manière qui ne lui plait pas, il
>> le modifie à la manière qui lui plait, pour l'enregistrer et le
>> resservir plus tard ...
> 
> Exactement. « Gloire à Apple ! Merci notre maître de nous préserver de la
> tentation d'aller voir ailleurs si l'herbe est plus grasse. »

T'es lourd avec ça... Mais t'as raison, en 1998 Apple a décidé 
d'emmerder sciemment ses 0,001% de clients qui utiliseraient peut-être 
rsync entre un Mac et PC Linux dans le futur.

-- 
"...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
ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

[toc] | [prev] | [next] | [standalone]

#7944

pehache , dans le message <j9qpmiFcinqU1@mid.individual.net>, a écrit :
> T'es lourd avec ça...

Et toi t'es lourd à répondre pour défendre l'indéfendable.

[toc] | [prev] | [next] | [standalone]

#7945

Le 21/03/2022 à 13:30, Nicolas George a écrit :
> pehache , dans le message <j9qpmiFcinqU1@mid.individual.net>, a écrit :
>> T'es lourd avec ça...
> 
> Et toi t'es lourd à répondre pour défendre l'indéfendable.

Qualifier d'"indéfendable" le choix, en 1998 de l'UFT-8 NFD au lieu de 
l'UTF-8 NFC, sans en plus que c'est complètement transparent pour 99,99% 
des utilisateurs et des usages, c'est juste ridicule.

[toc] | [prev] | [next] | [standalone]

#7919

Le 17/03/2022 à 00:18, Nicolas George a écrit :
> Thomas , dans le message
> <fantome.forums.tDeContes-BED480.00060817032022@news.free.fr>, a écrit :
>> Destination : par défaut sous Mac OS X, HFS+.
> 
> Vérifie si les caractères accentués ont été mis sous une forme canonique
> différente. Je crois me rappeler qu'Apple a décidé d'utiliser une forme
> décomposée, parce que faire comme tout le monde ça leur arracherait la
> gueule et pour embêter gratuitement les gens qui voudraient utiliser autre
> chose que des Appleries.

Vu la proportion de clients Apple qui doivent utiliser rsync en direct, 
cette motivation me parait peu probable.

[toc] | [prev] | [next] | [standalone]

#7921

pehache , dans le message <5rcY_IgRAIkSKR4HTIxdrE41uaU@jntp>, a écrit :
> Vu la proportion de clients Apple qui doivent utiliser rsync en direct, 
> cette motivation me parait peu probable.

Je n'ai pas suggéré qu'Apple avait fait ce changement précis pour
enquiquiner sur ce cas précis. Ce qui est vrai, c'est qu'Apple a la
politique générale de ne jamais faire comme tout le monde pour enquiquiner
les potentiels traîtres dans tous les cas.

[toc] | [prev] | [next] | [standalone]

#7923

In article <62333bf1$0$24261$426a34cc@news.free.fr>,
 Nicolas George <nicolas$george@salle-s.org> wrote:

> pehache , dans le message <5rcY_IgRAIkSKR4HTIxdrE41uaU@jntp>, a écrit :
> > Vu la proportion de clients Apple qui doivent utiliser rsync en direct, 
> > cette motivation me parait peu probable.
> 
> Je n'ai pas suggéré qu'Apple avait fait ce changement précis pour
> enquiquiner sur ce cas précis. Ce qui est vrai, c'est qu'Apple a la
> politique générale de ne jamais faire comme tout le monde pour enquiquiner
> les potentiels traîtres dans tous les cas.

et c'est bien pour ça (en partie) que j'ai décidé de prendre la 
tangente !
le pb, c'est qu'une période de transition est nécessaire ...

-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

[toc] | [prev] | [next] | [standalone]

#7928

Le 17/03/2022 à 14:47, Nicolas George a écrit :
> pehache , dans le message <5rcY_IgRAIkSKR4HTIxdrE41uaU@jntp>, a écrit :
>> Vu la proportion de clients Apple qui doivent utiliser rsync en direct, 
>> cette motivation me parait peu probable.
> 
> Je n'ai pas suggéré qu'Apple avait fait ce changement précis pour
> enquiquiner sur ce cas précis. 

Ca y ressemble quand même : "Je crois me rappeler qu'Apple a décidé 
d'utiliser une formedécomposée, parce que faire comme tout le monde ça 
leur arracherait lagueule et pour embêter gratuitement les gens qui 
voudraient utiliser autrechose que des Appleries."

> Ce qui est vrai, c'est qu'Apple a la
> politique générale de ne jamais faire comme tout le monde 

C'est assez vrai, il ont parfois le syndrôme NIH (Not Invented Here)

> pour enquiquiner
> les potentiels traîtres dans tous les cas.

Dans certains cas c'est sûrement vrai, mais en faire une grille de 
lecture systématique c'est une interprétation abusive. 

[toc] | [prev] | [next] | [standalone]

#7918

Le 17/03/2022 à 00:06, Thomas a écrit :
> bonjour :-)
> 
> 
> j'ai un pb avec rsync :
> 
> l'option '--delete-after' m'efface tous les fichiers dont le nom 
> contient des caractères non-ascii, aussitôt après les avoir copiés.
> 
> 
> il est probable que le pb soit lié au fait que rsync soit utilisé en 
> milieu hétérogène (mais je pensais que rsync était rodé à ce genre de 
> cas de figure un peu biscornu) :
> 
> systèmes de fichiers :
> Source : par défaut sous Ubuntu, je crois bien que c'est ext4.
> Destination : par défaut sous Mac OS X, HFS+.

Le rsync est lancé côté Ubuntu ou côté Mac ?

Le transfert se fait par un montage de disque (SMB, NFS,...) ou par une 
connexion SSH ?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | fr.comp.os.unix

csiph-web