Je ne peux pas corriger mon post :-(
Il fallait lire ctrl-H et "touch actrl-Hz" (taper "a ctrl-v ctrl-h z" sans les espaces sous bash, le caractère d'échappement ctrl-v peut-être différent selon les shells).
Justement, je pensais spécifiquement à unicode, et UTF en particulier. Ma question était plutôt "quels caractères non affichables" poseraient un soucis particulier? Pour moi, ça n'a rien à voir. Toutefois, certains caractères seront interdits sur CIFS (et peut-être plus, selon le système de fichiers sous jacent côté serveur). Les noms de fichiers trop longs pourront aussi poser un soucis.
Le fait que rsync pose un soucis n'est en rien lié au fait d'avoir des caractères "affichables" ou non. Par exemple, le backspace (H) que tu cites est tout à fait valide sur beaucoup de systèmes de fichiers. Selon le terminal que tu utilises, il pourra être affiché comme un backspace (donc en supprimant le caractère précédent), ou comme un "?", etc…
Exemple, sur une freebox montée par CIFS, avec un terminal "xfce4-terminal":
br@lorien:/mnt/freebox/www$ touch aHz
br@lorien:/mnt/freebox/www$ ls -l
total 0
-rw-rw-r-- 1 br br 0 Apr 5 11:56 a?z
drwxrwxr-x 4 br br 0 Mar 30 11:01 Books
On peut supposer que ni le SMB-1 ni le SMB-2 (source et destination du backup) ne supportent rsync/ssh, sinon il n'y aurait pas les 2 montages. Sans doute des "NAS" simples, avec des serveurs Samba pas vraiment contrôlables (sinon le problème de minuscules/majuscules serait réglé).
De même, je supposerais que RPI-1 et RPI-2 sont distants (pas sur le même réseau local), sinon 1) les deux sambas seraient montés sur un seul RPI, pour éviter une étape, et 2) la compression ne serait pas activée (trop pénalisant pour les Rpi sur un réseau rapide). Par exemple le soucis se poserait entre deux Freebox, si quelqu'un les utilisait comme espace de stockage d'un réseau local, les 2 box étant backupées l'une sur l'autre via des RPI. Ou un truc comme ça :)
Oui, ça m'intéresse. J'avais eu le soucis (minuscules/majuscules) sur un serveur samba, et j'avais fini par supprimer toutes les "collisions" côté client…
Evidemment, la fonction "-" ne fait pas la somme de tous les elements pour en changer le signe a la fin... Il prend le premier, et en soustrait les suivants...
L'exemple donne a donc pour resultat -40, et non -60...
Ca fait longtemps que j'utilise des versions chinoises de Linux (Red Flag & Bluepoint), parce-que ma femme est chinoise. Ces systemes sont tres corrects, et n'ont rien a envier a un Redhat ou a un Suse. Tous ces commentaires me font un peu rigoler, comme si Linux etait qq chose qui doit etre americain ou europeen. Les distribs asiatiques (Japon, Chine, Coree, Inde, etc...) existent depuis longtemps et sont souvent d'un tres bon niveau. Pour info, un lien vers la meilleure distrib Chinoise (Bluepoint): http://www.bluepoint.com.cn/english/(...)
A mon humble avis, il y a une difference entre les contrats "regie" (ou l'employe est base chez le client pour une duree [in]determinee), et les contrats "forfaits", ou la societe de service vend un resultat.
Dans le premier cas, je ne crois pas que la GPL soit violee (on peut considerer les developpements comme internes a la societe cliente).
Dans le second, le produit final est bien vendu (pas de produit = pas de sous). Dans ce cas, les modifications de sources GPL peuvent etre considerees comme litigieuses...
Desole pour les (inexistants) accents. Essayez un clavier nippon, et vous me pardonnerez ;-)
[^] # Re: A vérifier :
Posté par Bruno Raoult (site web personnel) . En réponse au message rsync oublie des fichiers. Évalué à 1.
Je ne peux pas corriger mon post :-(
Il fallait lire ctrl-H et "touch actrl-Hz" (taper "a ctrl-v ctrl-h z" sans les espaces sous bash, le caractère d'échappement ctrl-v peut-être différent selon les shells).
[^] # Re: A vérifier :
Posté par Bruno Raoult (site web personnel) . En réponse au message rsync oublie des fichiers. Évalué à 1.
Justement, je pensais spécifiquement à unicode, et UTF en particulier. Ma question était plutôt "quels caractères non affichables" poseraient un soucis particulier? Pour moi, ça n'a rien à voir. Toutefois, certains caractères seront interdits sur CIFS (et peut-être plus, selon le système de fichiers sous jacent côté serveur). Les noms de fichiers trop longs pourront aussi poser un soucis.
Le fait que rsync pose un soucis n'est en rien lié au fait d'avoir des caractères "affichables" ou non. Par exemple, le backspace (H) que tu cites est tout à fait valide sur beaucoup de systèmes de fichiers. Selon le terminal que tu utilises, il pourra être affiché comme un backspace (donc en supprimant le caractère précédent), ou comme un "?", etc…
Exemple, sur une freebox montée par CIFS, avec un terminal "xfce4-terminal":
br@lorien:/mnt/freebox/www$ touch aHz
br@lorien:/mnt/freebox/www$ ls -l
total 0
-rw-rw-r-- 1 br br 0 Apr 5 11:56 a?z
drwxrwxr-x 4 br br 0 Mar 30 11:01 Books
[^] # Re: A vérifier :
Posté par Bruno Raoult (site web personnel) . En réponse au message rsync oublie des fichiers. Évalué à 1.
Que veut dire caractère non affichable, pour toi?
[^] # Re: La suite
Posté par Bruno Raoult (site web personnel) . En réponse au message rsync oublie des fichiers. Évalué à 1.
C'est déjà ce qu'il fait (le rsync est sur ssh d'après la ligne de commande). Donc, si j'ai bien compris, le schéma actuel est:
SMB-1 <-- (montage smb) --> RPI-1 <-- (rsync/ssh) --> RPI-2 <-- (montage smb) --> SMB-2
On peut supposer que ni le SMB-1 ni le SMB-2 (source et destination du backup) ne supportent rsync/ssh, sinon il n'y aurait pas les 2 montages. Sans doute des "NAS" simples, avec des serveurs Samba pas vraiment contrôlables (sinon le problème de minuscules/majuscules serait réglé).
De même, je supposerais que RPI-1 et RPI-2 sont distants (pas sur le même réseau local), sinon 1) les deux sambas seraient montés sur un seul RPI, pour éviter une étape, et 2) la compression ne serait pas activée (trop pénalisant pour les Rpi sur un réseau rapide). Par exemple le soucis se poserait entre deux Freebox, si quelqu'un les utilisait comme espace de stockage d'un réseau local, les 2 box étant backupées l'une sur l'autre via des RPI. Ou un truc comme ça :)
[^] # Re: La suite
Posté par Bruno Raoult (site web personnel) . En réponse au message rsync oublie des fichiers. Évalué à 1.
Oui, ça m'intéresse. J'avais eu le soucis (minuscules/majuscules) sur un serveur samba, et j'avais fini par supprimer toutes les "collisions" côté client…
[^] # Re: Concours de la plus grosse ping
Posté par Bruno Raoult (site web personnel) . En réponse au sondage ping linuxfr.org me donne. Évalué à 1.
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=1 ttl=50 time=269 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=2 ttl=50 time=268 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=3 ttl=50 time=266 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=4 ttl=50 time=266 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=5 ttl=50 time=268 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=6 ttl=50 time=268 ms
^C
--- linuxfr.org ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5018ms
rtt min/avg/max/mdev = 266.196/267.986/269.418/1.287 ms
# Erreur dans le second exemple de lisp
Posté par Bruno Raoult (site web personnel) . En réponse à la dépêche Développement d'un mode mineur avec Emacs. Évalué à 3.
L'exemple donne a donc pour resultat -40, et non -60...
My 2 cents.
# Linux en Chine
Posté par Bruno Raoult (site web personnel) . En réponse à la dépêche Test de Red Flag: la distribution de l'Empire du Milieu. Évalué à 10.
[^] # Re: Il y a confusion il me semble
Posté par Bruno Raoult (site web personnel) . En réponse à la dépêche Les sociétés de services ne violent-elles pas la GPL ?. Évalué à 1.
Dans le premier cas, je ne crois pas que la GPL soit violee (on peut considerer les developpements comme internes a la societe cliente).
Dans le second, le produit final est bien vendu (pas de produit = pas de sous). Dans ce cas, les modifications de sources GPL peuvent etre considerees comme litigieuses...
Desole pour les (inexistants) accents. Essayez un clavier nippon, et vous me pardonnerez ;-)