HyperBackup Sicherung auf extFS HD - invalide Zeichen in Dateien ein Problem?

[B00ber]

Hallo zusammen,

ich sichere mittels meine Synology 218+ (ca. 8TB) per HyperBackup auf eine externe (10TB) HD. Die Backup HD ist mit ext4 als Filesystem formatiert. Mein Hauptrechner ist ein Mac und ich habe nach dem letzten Backup endlich mal das Backup auf der Backup HD gründlich gecheckt und geschaut ob ich es im Fehlerfall auch auf meinem Mac lesen kann - bisher hatte ich immer vertraut das alles i.O. ist, wenn der HyperBackup Job durchgelaufen war (ich sichere monatlich).

Ich habe mir daraufhin extFS for Mac gekauft und die Backupplatte ausgelesen - und war beruhigt, dass alles so gebackuppt wurde wie ich es erwarte (das beruhigt). Allerdings habe ich bei einigen Dateien auf meiner Synology leider nicht aufgepasst und in manche Dateien ein unerlaubtes Zeichen im Dateinamen verwendet: ein "/". Ich habe das leider zu spät gemerkt und erst im Backup stichprobenhaltig gesehen.

Die Dateien haben das "/" folgendermaßen im Namen: "Vol. 18 No. 2 / Vol. 18 No. 3". Auf meiner per extFS gesicherten Backupplatte wird das "/" als invalides Zeichen angezeigt, das Backup ist aber trotz dem invalidem Zeichen immer normal durchgelaufen. Siehe Screenshot.

Frage: können die "/" für das Backup ein Problem sein oder sollte ich die besser auf der Quelle korrigieren? Gibt es irgendeine Möglichkeiten diese Art von invaliden (zumindest für extFS invalid) Zeichen, bzw. die relevanten Dateien, zu suchen/finden? Ich weiss nicht in wievielen Dateien ich das "/" habe, aber es sind sicher 15-20 verstreut.

 

[dil88]

Ich persönlich würde diese Dateinamen umbenennen. Wenn Du sie aber unbedingt behalten willst, würde ich zumindest eine davon wiederherstellen und schauen, ob das sauber funktioniert. Machst Du ein versioniertes oder ein nichtversioniertes HyperBackup? Ich vermute, Du machst ein versioniertes. Dann sollte das Filesystem keine Rolle spielen, weil die Daten in Form einer Datenbankstruktur in eine Datei geschrieben werden.

 

[w00dcu11er]

Am besten ausschließliche UTF-8 kompatible Zeichen in Dateinamen verwenden; d.h. "/" gehört nicht dazu.

 

[synfor]

Das Problem ist nicht fehlende UTF-8-Kompatibilität, sondern dass das Zeichen auf vielen Systemen im Dateinamen nicht zulässig ist.

 

[patrickn]

Eben, / ist definitiv utf-8 konform - man findet es bspw. auf jeder Website, die für gewöhnlich in utf8 codiert sind. Oder Linux, alles voller "/"

Und gerade weil es zu Pfadangaben gehört, hat das nix im Dateinamen zu suchen

 

[B00ber]

Danke für Eure Rückmeldungen! Ich würde die Dateinamen gerne korrigieren ... das Problem ist: wie finde ich die betroffenen Dateien? Hat jemand einen Tip, wie ich alle Dateien, die ein "/" im Namen haben, filtern kann? Ich kann es auf einen Unterordner definitiv einschränken, es sind aber leider einige Tausend Dateien, die durchgesucht werden müssten.

Ich habe es über meinen macOS Dateimanager (Forklift) mit Zugriff auf das Laufwerk der Synology versucht, bei Suche nach "/" findet er jedoch nichts.

 

[bertoal]

das kann bestimmt @dil88 's Umbenennungsprogramm mit der coolen nostalgischen 3.11-Benutzeroberfläche !

 

[Hagen2000]

macOS benutzt intern den Doppelpunkt ':' zur Pfadtrennung, Windows den Backslash '\' und Linux den normalen Slash '/'.
Daher ist der normale Slash erst einmal ein zulässiges Zeichen in Dateinamen unter macOS.

Wird eine Datei mit Slash im Namen auf beispielsweise ein SMB-Laufwerk kopiert, so ersetzt macOS den Slash durch das Unicode Zeichen U+F022 (hex EF 80 A2). Dieses wird dann als kleines Kästchen mit Fragezeichen oder einem anderen Auslassungzeichen auf anderen Plattformen dargestellt, da das Zeichen in der "private use area" von Unicode liegt und keine Glyphe (grafische Darstellung) hat. Damit wird das Problem vermieden, dass andere Plattformen das Zeichen als Pfadtrenner sehen. macOS kann das Zeichen dann beim Zurückkopieren einfach wieder zurückwandeln. Leider habe ich zu diesem Verhalten keine offizielle Dokumentation von Apple finden können.

Zur Eingangsfrage kann man also sagen, dass die Datei fehlerfrei gesichert wird und aus Sicht von macOS kein Handlungsbedarf besteht. Da das Zeichen zwar nicht darstellbar ist, aber ein gültiges UTF-8-Zeichen ist, sollten auch andere Systeme damit zurecht kommen (ähnlich wie beispielsweise mit chinesischen Schriftzeichen im Dateinamen).

Um die Dateien zu finden, kann man sehr einfach im macOS-Terminal folgenden Befehl verwenden. Dabei kommt jedoch eine Besonderheit zu Tage: Die Kommandozeilen-Utilities stellen den Slash als Doppelpunkt dar (warum auch immer). Also das Programm Terminal öffnen. Dann befindet man sich im eigenen Home-Verzeichnis und kann von dort aus beispielsweise folgende Suche starten:

find Documents -type f -name "*:*"

Findet alle Dateien, die einen Doppelpunkt enthalten im Ordner "Dokumente" - man muss auf Kommandozeilenebene den nicht lokalisierten Namen "Documents" benutzen.

 

[B00ber]

Wow, ganz lieben Dank @bertoal für diese ausführliche Info! Absolut top. Damit hast Du eigentlich alles beantwortet. Danke auch für das Snippet zum Finden der Dateien, das werde ich testen. Eine letzte Frage noch dazu: die"fehlerhaften" Dateien liegen alle auf einer Partition der Synology, die ich über eine SMB Freigabe mit meinem macOS Filemanager manage.

Kann (muss?) ich mich dazu per SSH auf die Synology tunneln um Dein Snippet dann mit angepasstem Pfad lokal auf der Synology die Files zu suchen?

Mit Deinem Script finde ich die Dateien ja auf macOS Ebene - es handelt sich hierbei jedoch um mehrere Tausend PDF Dateien, die allesamt auf der Synology sind.

Kann ich mich auf die Synology per SSH schalten und dann soetwas auf der Shell machen: ?

find /meinSynologyPfad -type f -name "*/*"

 

[bertoal]

ääääh, bitte bitte, aber die Ehre gebührt @Hagen2000

 

[B00ber]

Ach Mist, falsch getagged - ich meinte natürlich @Hagen2000 . Sorry, das kommt davon wenn man hier während der Arbeit und laufenden Meetings tippt. Danke natürlich auch für Deinen Input @bertoal!

 

[Hagen2000]

Vom macOS Terminal aus arbeitest Du so:

find /Volumes/meinSynologyPfad -type f -name "*:*"

Unter /Volumes liegen die externen Laufwerke, ggf. mit ls /Volumes schauen, wie sie konkret heißen.

Wenn Du dich per SSH auf dem NAS einloggst, dann schaut die Sache anders aus:

find /volume1/meinSynologyPfad -type f -name "**"

Unter /volume1 liegen in der Regel die Freigaben (wenn Du mehrere Volumes hast, entsprechend die Zahl erhöhen), ggf. mit ls /volume1 schauen, wie sie konkret heißen.
Du siehst in meiner Anweisung jetzt zwischen den Sternchen das Unicode-Zeichen U+F022. Am besten hier raus kopieren, denn Du kannst es ja nicht eingeben.

 

[B00ber]

Hi @Hagen2000 - tausend Dank für Deinen super Support! Das hat geklappt Bin per SSH drauf und habe dann direkt an der Wurzel rekursiv (zur Sicherheit) alle Files durchsucht ... nicht nur das eine Unterverzeichnis, wo ich die "kaputten" Filenamen vermutet habe, sondern alles. Immer beeindruckend wenn man auf der Shell mal eben so zehntausende Dateien innerhalb 2 Sekunden durchsucht und dann die relevanten ausspuckt!

Letzte Frage dann dazu: es sind ca. 40 Files oder so, die ich nun über den Mac Filemanager ganz normal "korrigieren" werde - also das "/" raus aus dem Dateinamen. Übrigens @dil88 : zu Deiner Eingangsfrage noch das Feedback: ich habe ein Einzelversion-Backup von HyperBackup (also ein 1:1 Abbild). Beim nächsten inkrementellen Backup das ich dann fahre werden sich die korrigierten Filenamen aus quasi aus dem Backup rauswachsen...

Bei den 40 Files ist mir aber bei der Ausgabe auf der Shell aufgefallen, dass jede gefundene Datei immer zweimal aufgelistet wird. Siehe Screenshot rot markiert - was hat die zweite Datei zu jeder Datei dort genau für eine Bedeutung? (bin das erste mal per SSH auf die Synology...)

Und eine allerletzte Bonusfrage: ist ein "@" im Ordner oder Dateinamen bei extFS ein Problem (invalid)? Ich vermute nein, da es bei meiner rekursiven Suche auch nicht mit in dem Suchresultat ausgegeben wurde. Es handelt sich hierbei um diverse Scans alter Magazine, die das @ im Titel haben und die ich auf der Synology speichere.

 

[dil88]

In den @eaDir-Verzeichnissen werden Metadaten aus der Indizierung des DS gespeichert. Die kannst Du ignorieren. Das @ ist dementsprechend kein Problem im Datei- oder Verzeichnisnamen. Schön, dass Du das Thema abschließen konntest!

 

[B00ber]

Alles klar, Danke @dil88 für die Erläuterung. Ich weiß dann was zu tun ist (Dateinamen fixen bis zum nächsten, inkrementellen Backupjob). Danke für die großartige Hilfe an alle, Thread ist damit quasi gelöst.