Linux: wie finde ich "unmögliche" zeichen in dateinamen?
guten tag
nach stundenlangen studium von "dem kofler" und anderen grundlagenwerken weiss ich nicht weiter.
es geht um folgendes:
eine NAS von qnap. drauf ist ein linux (es gibt keine exakte bezeichnund dafür!), shell-aufgaben erledigt die BusyBox [v1.01 (2015.01.25-18:35+0000) multi-call binary]. IRGENDWANN vor einigen jahren hat es meinerseits wohl versuche gegeben, mit robocopy oder anderen (windows)kopierern dateien raufzukopieren. da muss einiges (aber weniges!) schief gegangen sein.
wenn ich heutzutage mit meinen robocopy-scripts rangehe, um von einer NAS auf die backup-NAS zu kopieren, bekomme ich wenige (aber störende!) fehlermeldungen wie:
\\qnap\allegro\_DATA\STN\_intranet_alt\www\scripts\ruckzuck\php_neu\bilder\ Zlter
2015/02/04 08:59:48 FEHLER 123 (0x0000007B) Folgende Datei wird kopiert \\qnap\allegro\_DATA\STN\_intranet_alt\www\scripts\ruckzuck\php_neu\bilder\
Die Syntax f?r den Dateinamen, Verzeichnisnamen oder die Datentr"gerbezeichnungist falsch.
\\qnap\allegro\_DATA\TZM\
\\qnap\allegro\_DATA\TZM\_boehlke\
....
auf den ersten blick übersieht man das leicht. aber in wirklichkeit gibt es auf der quellen-NAS, wenn man mit dem mc raufschaut, eine datei, die hat einen umlaut, der aber als klötzchen angezeigt wird. es ist m.E. hex81, das kann man sehen, wenn man ls > datei macht, und mit dem mc und F3 und hex-modus sich das anschaut.
ist dieser umlaut IN EINEM subdir enthalten, dann rastet robocopy völlig aus, und verweigert jegliche kopiererei im dazugehörigen stammverzeichnis. da gibt es dann plötzlich "leere" verzeichnisse oder so. das bedeutet auf dem backup-NAS datenverlust.
ich habe nun mit windowsmitteln KEINE change, mich den sudirs zu nähern. windows kann sie nicht einlesen. ich muss also auf der linux-ebene weitermachen.
OK!
Frage: wie findet man in linux dateien und oder unterverzeichnisse, die "unmögliche" zeichen haben?
man kann ja damit anfangen, erstmal alle deutschen umlaute abzufragen. oder nur das deutsche "ü" (hex81).
ich denke, das geht, oder müsste gehen mit: find
mein test hat aber nichts gebracht:
sh-3.2# find . -type f -name \*\h81\*
./RSB/_neu_2012_7/hans2000/prg/h816
ok. abwandlungen wie:
sh-3.2# find . -type f -name \*\x81\*
sh-3.2# find . -type f -name ~\*\x81\*~
sh-3.2# find . -type f -name ~*\x81*~
bringen aber nichts!
da, ab dem punkt ist aber eine datei die "ein klötzchen" im namen drin hat.....
was mir klar ist: mit \ muss ich escapen
aber ~ scheint nichts zu bringen.
und: ich hoffe, daß die BusyBox das "original"-find eingebaut hat. und nicht nur einen geringeren umfang uns gibt....
ein weg, der mir übrigbleibt: alle robocopy-logdateien nach "FEHLER 123" per hand zu durchsuchen, und dann weiter in der Nähe des angegebenen ortes suchen. (3 TB warten auf mich, mit riesigen zeichenbäumen..... ;-(
letzte die ?entscheidende? frage:
wie kann man mit find nach einem hex-wert suchen?
\x81 klappt nicht.
danke fürs mitdenken
euer klaus(i)
nach stundenlangen studium von "dem kofler" und anderen grundlagenwerken weiss ich nicht weiter.
es geht um folgendes:
eine NAS von qnap. drauf ist ein linux (es gibt keine exakte bezeichnund dafür!), shell-aufgaben erledigt die BusyBox [v1.01 (2015.01.25-18:35+0000) multi-call binary]. IRGENDWANN vor einigen jahren hat es meinerseits wohl versuche gegeben, mit robocopy oder anderen (windows)kopierern dateien raufzukopieren. da muss einiges (aber weniges!) schief gegangen sein.
wenn ich heutzutage mit meinen robocopy-scripts rangehe, um von einer NAS auf die backup-NAS zu kopieren, bekomme ich wenige (aber störende!) fehlermeldungen wie:
\\qnap\allegro\_DATA\STN\_intranet_alt\www\scripts\ruckzuck\php_neu\bilder\ Zlter
2015/02/04 08:59:48 FEHLER 123 (0x0000007B) Folgende Datei wird kopiert \\qnap\allegro\_DATA\STN\_intranet_alt\www\scripts\ruckzuck\php_neu\bilder\
Die Syntax f?r den Dateinamen, Verzeichnisnamen oder die Datentr"gerbezeichnungist falsch.
\\qnap\allegro\_DATA\TZM\
\\qnap\allegro\_DATA\TZM\_boehlke\
....
auf den ersten blick übersieht man das leicht. aber in wirklichkeit gibt es auf der quellen-NAS, wenn man mit dem mc raufschaut, eine datei, die hat einen umlaut, der aber als klötzchen angezeigt wird. es ist m.E. hex81, das kann man sehen, wenn man ls > datei macht, und mit dem mc und F3 und hex-modus sich das anschaut.
ist dieser umlaut IN EINEM subdir enthalten, dann rastet robocopy völlig aus, und verweigert jegliche kopiererei im dazugehörigen stammverzeichnis. da gibt es dann plötzlich "leere" verzeichnisse oder so. das bedeutet auf dem backup-NAS datenverlust.
ich habe nun mit windowsmitteln KEINE change, mich den sudirs zu nähern. windows kann sie nicht einlesen. ich muss also auf der linux-ebene weitermachen.
OK!
Frage: wie findet man in linux dateien und oder unterverzeichnisse, die "unmögliche" zeichen haben?
man kann ja damit anfangen, erstmal alle deutschen umlaute abzufragen. oder nur das deutsche "ü" (hex81).
ich denke, das geht, oder müsste gehen mit: find
mein test hat aber nichts gebracht:
sh-3.2# find . -type f -name \*\h81\*
./RSB/_neu_2012_7/hans2000/prg/h816
ok. abwandlungen wie:
sh-3.2# find . -type f -name \*\x81\*
sh-3.2# find . -type f -name ~\*\x81\*~
sh-3.2# find . -type f -name ~*\x81*~
bringen aber nichts!
da, ab dem punkt ist aber eine datei die "ein klötzchen" im namen drin hat.....
was mir klar ist: mit \ muss ich escapen
aber ~ scheint nichts zu bringen.
und: ich hoffe, daß die BusyBox das "original"-find eingebaut hat. und nicht nur einen geringeren umfang uns gibt....
ein weg, der mir übrigbleibt: alle robocopy-logdateien nach "FEHLER 123" per hand zu durchsuchen, und dann weiter in der Nähe des angegebenen ortes suchen. (3 TB warten auf mich, mit riesigen zeichenbäumen..... ;-(
letzte die ?entscheidende? frage:
wie kann man mit find nach einem hex-wert suchen?
\x81 klappt nicht.
danke fürs mitdenken
euer klaus(i)
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 262256
Url: https://administrator.de/forum/linux-wie-finde-ich-unmoegliche-zeichen-in-dateinamen-262256.html
Ausgedruckt am: 23.12.2024 um 15:12 Uhr
5 Kommentare
Neuester Kommentar