Windows -> Linux = Karakter encoding prolbeem?

[Q]

Ik wil graag mijn MP3 colletie middels rsync 1 op 1 kopieren van windows naar een Linux backup server. Dat deed ik ooit eerst met een windowstooltje over samba, maar dat rsync werkt beter.

Beiden hebben ze echter het volgende probleem. Ik heb een bestand met deze naam:

Lakmé! LAkmé! qu'as-tu?... C'est lui! C'est lui!

Dit gaat dus totaal mis onder Linux. Als ik dit onder windows kopieer, allemaal geen probleem, de machine gaat hier prima mee om.

Onder linux krijg ik dit resultaat:

Lakm?! LAkm?! qu'as-tu... C'est lui! C'est lui!

Dit vanuit een terminal venster ge c/p'd. Dit geeft allerlei problemen met samba en bovendien: de backup is niet 1-op-1 want de bestandsnamen kloppen niet meer.

Ik heb zo'n vermoeden dat ik onder Linux ergens iets aan de character encoding moet doen maar wat, waar en hoe, ik zou niet eens weten waar ik moet beginnen met zoeken.

Het gaat dus duidelijk om tekens als é of ë etc.

Edit: het is iig geen specifiek filesystem probleem, het speelt zowel onder reiserfs als onder ext3.

[ Voor 14% gewijzigd door Q op 17-10-2004 22:20 ]

[usr-local-dick]

Ik wil graag mijn MP3 colletie middels rsync 1 op 1 kopieren van windows naar een Linux backup server. Dat deed ik ooit eerst met een windowstooltje over samba, maar dat rsync werkt beter.

Vraagje hoe precies gaan de files over?
Dus van windows -> (rsync) -> linux?

Hoe draai je rsync op windows dan???

[Q]

usr-local-dick schreef op 17 oktober 2004 @ 23:07:
[...]


Vraagje hoe precies gaan de files over?
Dus van windows -> (rsync) -> linux?

Hoe draai je rsync op windows dan???

Ik heb getest met rsync, gewoon samba file copy en scp (ssh). Allemaal het zelfde probleem. Getest met verschillende kernels. Zelfde probleem.

Wat valt op: als ik met een windows tooltje ga kijken: bijvoorbeeld winscp dan zie ik dus wel de juiste characters, zoals é.

Ik ben hier niet blij mee. Zoals het er nu naar uit ziet ga ik een apparte linux machine inrichten voor mijn website test omgeving en een aparte windowz machine om fatsoenlijk backups te kunnen maken.

Daarnaast sync ik de mp3-collectie weer van die server met mijn ibook en dan krijg ik allemaal foutmeldingen van rsync, betreffende deze bestandsnamen.

offtopic:
Rsync onder windows -> met cygwin kom je een heel eind.

Edit: Ik heb dit alles ook even met mijn ibookje getest (freebsd). Ik zie het volgende:

- rsync stikt op die rare bestandsnamen
- scp stik top die rare bestandsnamen
- als ik zo'n rare bestandsnaam gewoon van windows naar mijn mac kopieer middels samba dan is er niets loos. Het bestand wordt netjes aangemaakt en onder mac os x finder ziet het bestand er ook normaal uit, met de é's in tact.

Het lijkt er nu steeds meer op dat het meer een probleem is van de gebruikte software die niet met deze karakters kan omgaan.

[ Voor 23% gewijzigd door Q op 17-10-2004 23:27 ]

[usr-local-dick]

ik begrijp nog steeds niet wat je nu precies probeert to doen en hoe??
leg eens duidelijk uit, het gaat hier zo te zien om details

[0siris]

usr-local-dick schreef op 17 oktober 2004 @ 23:30:
ik begrijp nog steeds niet wat je nu precies probeert to doen en hoe??
leg eens duidelijk uit, het gaat hier zo te zien om details

zo te zien rsync in windows aan de praat gekregen, hiermee pobeert-ie bestanden vanuit windows naar linux te rsyncen (linux bak = backup bak)

[DumbAss]

Ik heb helaas hetzelfde probleem. Als ik een bestand met een speciaal character in de naam naar een linux share kopieer vernaggelt hij ook de naam. Ik heb er nog steeds geen oplossing voor gevonden.

[Wolfboy]

misschien meer character encodings aanzetten in de kernel?

[MBV]

je kan eens kijken in welke character encoding je bak nu draait: UTF-8 of iso-8859-X. Je kan eens kijken wat er gebeurt als je de andere kiest, en eens proberen een bestand met een speciaal teken onder linux aan te maken.

Dit wordt een bookmark: ik hoop dat iemand een oplossing heeft, ik heb het probleem zelfs als ik via samba kopieer irritant met foto's waarin een € of ' ofzo voorkomt... "mbv's foto's" -> "mbv?s foto?s"

[Q]

Ik kopieer bestanden via rsync of gewoon via samba of zelfs via scp van een windows machine naar een linux machine.


Probleem 1
Vervolgens browse ik via samba naar die bestanden, waaronder deze bestanden met die gekke tekens. Het gevolg is dat ik geen bestanden zie, die er wel zijn, als ik even met een ssh terminal en een simpele 'ls -al' ga kijken.

Als ik niet met mijn windows bak via samba ga kijken maar met mijn Ibook via samba dan heb ik precies het zelfde probleem. Ik zie geen bestanden die er wel zijn.

probleem 2
Als ik vervolgens die bestanden middels rsync van deze linux bak middels rsync op mijn ibook probeer te krijgen heb ik ook problemen vanwege de bestandsnamen.


Ik vraag mij dus af waar dit nu aan ligt.

[Q]

Wolfboy schreef op 17 oktober 2004 @ 23:47:
misschien meer character encodings aanzetten in de kernel?

Het rare is dat bijv winscp geen problemen heeft met deze bestandsnamen. Dus als ik via scp verbind dan zie ik wel gewoon alle é's enzo. Het lijkt mij eerder applicatie gebonden....

[0siris]

zoals ik het hier lees, heeft het met de cygwin implementatie van rsync te maken...

[Q]

0siris schreef op 18 oktober 2004 @ 00:04:
zoals ik het hier lees, heeft het met de cygwin implementatie van rsync te maken...

Ik heb precies het zelfde probleem met een gewone samba copy. Bovendien gaat dit over een backslash probleem en dat is dit zeker niet.

[ Voor 10% gewijzigd door Q op 18-10-2004 00:11 ]

[0siris]

Q schreef op 18 oktober 2004 @ 00:11:
Ik heb precies het zelfde probleem met een gewone samba copy. Bovendien gaat dit over een backslash probleem en dat is dit zeker niet.

daarnaast lees ik op rsync.samba.org dat zo'n beetje heel win32 op de todo lijst staat voor bugfixes. Toch is het raar dat ik er verder eigenlijk niets over kan vinden...

[DumbAss]

Wolfboy schreef op 17 oktober 2004 @ 23:47:
misschien meer character encodings aanzetten in de kernel?

Ikzelf heb UTF-8 aanstaan en ik zie net dat ISO 8859-1 mist. Ik ga hem aanzetten en de default op ISO 8859-1 zetten. Ik ben wel eens benieuwd of het helpt.

[Q]

Het volgende valt mij op. Onder linux zie ik dat mijn terminal de tekens als '?' weergeeft. Echter, doe ik bijv

#mv bestandsna<tab> dan zie ik dat de naam netjes wordt ge-escaped en zie ik zelfs de juiste tekens op het scherm.

Overigens lijkt het er op dat mac os x finder wel gewoon dit soort bestanden goed kan copieren, het ziet er alleen brak uit onder de terminal.

Bestandsuitwisseling met scp tussen mac en linux gaat ook prima. De tekens zien er niet uit, maar het werkt wel en onder de grafische schil zien de bestanden er goed uit.

[Q]

Inmiddels na wat geknoei kom ik er achter dat het zoals hierboven wordt gesuggereerd zeer waarschijnlijk een probleem met rsync onder windows is die niet goed omgaat met character encoding.

Nader onderzoek om dit te bevestigen zal vandaag niet meer plaatsvinden ivm sterke behoefte aan slaap.

[0siris]

Q schreef op 18 oktober 2004 @ 00:54:
Nader onderzoek...vandaag niet meer...ivm sterke behoefte aan slaap.

Da's zeker een winterslaap, niet?

[Q]

Nou.. zou wel prettig zijn.

Update: Stand van zaken.

Ik heb nu gewoon samba gebruikt om van PC -> LNX server te kopieren. Gaat goed, bestandsnamen blijven behouden en worden gewoon goed verwerkt.

Probleem: rsync van LNX server naar iBook (FreeBSD) gaat nog steeds niet lekker, maar dit is waarschijnlijk een specifiek rsync probleem.

-> Als ik nu rsync tussen ibook en server dan worden alle bestanden met tekens als éù etc. gezien als niet gelijk. Ze worden dus iedere keer gewist en overnieuw gekopieerd. Dat is heel irritant, want het gaat om nogal wat MB's.

Ik zal eerst eens testen tussen 2 linux systemen om te onderzoeken of het te maken heeft met mijn macje. Misschien dat Rsync deskundigen hier nog iets zinnigs over kunnen zeggen?

[usr-local-dick]

Je gebruikt toch wel overal samba3 he?
Versie 2 heeft gare UTF8 support nl, versie 3 support het helemaal goed...

Ik had vroeger ook ellende hiermee, maar nu alles op samba3 draait gaat het goed.

check deze web [rml][ debian -> rsync -> OSX] exotische filenames[/rml]

[Q]

usr-local-dick schreef op 18 oktober 2004 @ 20:30:
Je gebruikt toch wel overal samba3 he?
Versie 2 heeft gare UTF8 support nl, versie 3 support het helemaal goed...

Ik had vroeger ook ellende hiermee, maar nu alles op samba3 draait gaat het goed.

check deze web [rml][ debian -> rsync -> OSX] exotische filenames[/rml]

Hey, dat is iets wat ik ook nog gezien heb: maar dat kwam doordat ik rsync onder windows draaide. Toen ik alles van mijn winbak naar mijn linbak stuurde via samba (3.0nogwat!) ging het inderdaad prima. Maar rsync gaat nog steeds niet lekker tussen die data, (afkomstig van mijn winbak en op de linux bak gezet) die nu op de linuxbak staat en naar mijn aaiboek moet... probleem is dus: bestanden onnodig kopieren. Maar ik blijf testen.

[usr-local-dick]

Hey, dat is iets wat ik ook nog gezien heb: maar dat kwam doordat ik rsync onder windows draaide. Toen ik alles van mijn winbak naar mijn linbak stuurde via samba (3.0nogwat!) ging het inderdaad prima. Maar rsync gaat nog steeds niet lekker tussen die data, (afkomstig van mijn winbak en op de linux bak gezet) die nu op de linuxbak staat en naar mijn aaiboek moet... probleem is dus: bestanden onnodig kopieren. Maar ik blijf testen.

Dus zoiets?

code:

   xp ----(smb3)-------> linux  ------(rsync)------>  OSX
data ok                 data OK                    data verrot

[Q]

usr-local-dick schreef op 18 oktober 2004 @ 22:03:
[...]


Dus zoiets?

code:

   xp ----(smb3)-------> linux  ------(rsync)------>  OSX
data ok                 data OK                    data verrot

Ja dus. Het volgende gaat overigens perfect, bestanden met 'rare' tekens worden niet onnodig gesynchroniseerd.

code:

 Linux ---rsync------> linux

Ik moet nu dus uitzoeken wat er mis gaat tussen OSX en Loeniks.

edit: een sync zonder --delete gaat in ieder geval nu goed. Maar ik wil een exacte mirror hebben. Maar een --delete zorgt er voor dat alle 'gekke' bestandsnamen worden gewist en overnieuw worden verstuurd.

[ Voor 20% gewijzigd door Q op 18-10-2004 22:51 ]

[Q]

Ik heb het probleem opgelost door niet meer via de rsync daemon op de linux machine te synchroniseren maar via een samba share. Daar werkt delete ook goed mee. Het is niet helemaal ideaal, maar het werkt. Bedankt voor alle hulp.