MMC Replay Filebrowser: Artefakte durch Mac-Os Ordnerstruktur

Rotzwald · 12. Oktober 2015

Ich betreibe ein MMC Replay und ein Macbook Air unter OSX. Wenn ich Dateien vom Mac auf die SD-Karte spiele, zeigt der Filebrowser im MMC Replay immer auch Dateien an, die am Mac unsichtbar sind.
Jede zweite Zeile zeigt ein leeres .d64 File an, der Dateiname besteht immer aus nur einem Buchstaben und dem Kürzel .d64. Grundsätzlich stört das die Funktionalität zwar nicht, ist aber lästig, weil man dadurch ewig scrollen muss, um sein gewünschtes File zu erreichen. Außerdem ist es einfach hässlich.
Hat jemand Ahnung, wie ich das Problem beheben kann? Ich vermute es hängt mit dem HFS Filesystem von Apple zusammen.

Liebe Grüße,

OH

Messerjocke · 12. Oktober 2015

Da hilft in der Tat nur ein OS zu verwenden was nicht jeden eingelegten Datenträger mit Unsinn dichtmüllt.
Vielleicht kennt ja der ein oder andere Apfel-Jünger hier einen Trick wie man diese Unart abstellen kann.
Mit dem HFS wird es eher wenig zu tun haben, denn dann würde der Datenträger im MMCReplay gar nicht mehr lesbar sein.

spider-j · 12. Oktober 2015

Naja, man kann im Zweifel sicher auch mit OSX per terminal die entsprechenden Files einfach von der Karte löschen. Ist natürlich lästig. Evtl. wissen die Apple-Spezies hier 'ne bessere Methode...

Rotzwald · 12. Oktober 2015

Zitat von spider-j

Naja, man kann im Zweifel sicher auch mit OSX per terminal die entsprechenden Files einfach von der Karte löschen.

Im Terminal sehe ich die Artefakte auch nicht. Sie werden erst im MMc Replay Filebrowser sichtbar.

spider-j · 12. Oktober 2015

Zitat von Rotzwald

Im Terminal sehe ich die Artefakte auch nicht. Sie werden erst im MMc Replay Filebrowser sichtbar.

Hm. Das ist seltsam. Zur Sicherheit: Du nutzt aber schon den -a switch von ls?

Rotzwald · 12. Oktober 2015

Ich muss gestehen, so firm bin ich in der Shell nicht. ls geht grad noch, Parameter hab ich aber nicht definiert.

spider-j · 12. Oktober 2015

Ok. Dann guck dochmal, ob sie per

Code

ls -al

angezeigt werden. Falls ja, kannst Du die dann auch mit

Code

rm Dateiname.Dateiendung

löschen.

Am besten danach dann nicht mehr mit einem Dateibrowser (keine Ahnung, was da beim Mac standard ist) auf die Karte zugreifen, sondern nur noch auswerfen.

for(;;) · 13. Oktober 2015

In diesen Dateien speichert OSX Metainformationen ab, die es in anderen Dateisystemen als HFS(+) nirgends sonst ablegen kann. Genauso gut könnte ich fragen, wieso mir Windows immer eine thumbs.db in mein Verzeichnis legt, irgendwo müssen diese Betriebssysteme eben Informationen ablegen.

Unter unix-artigen Systemen beginnen "versteckte" Dateinamen mit einem Punkt und da Du wahrscheinlich keine versteckten Dateien auf Deiner SD-Karte haben möchtest -- und erst recht keine, die eigentlich versteckt sein sollten und es dann doch nicht sind -- ist es am einfachsten, rekursiv alle versteckten Dateien zu löschen.

Der Finder sollte dabei geschlossen sein, jedenfalls zumindest nicht das Inhaltsverzeichnis der SD-Karte irgendwo offen haben. Dann machst Du Dir ein Terminal auf.

Code

cd /Volumes/NAME-DER-SDKARTE

bringt Dich in das Verzeichnis der SD-Karte.

Code

rm -rf .*

Löscht dann dort rekursiv alle versteckten Dateien.

Anschließend die SD-Karte auswerfen:

Code

diskutil unmount NAME-DER-SDKARTE

Warnung:
Du solltest Dir ausgesprochen sicher sein, im richtigen Verzeichnis zu sein, bevor Du rm -rf .* startest!

Henning · 13. Oktober 2015

Zitat von for(;;)

rm -rf .*

STOP!
Dieses Glob-Pattern schließt .. mit ein, also das übergeordnete Verzeichnis! Dazu ist der Befehl rekursiv, löscht also bei entsprechender Berechtigung gleich das ganze Dateisystem...

Globs immer mit echo testen...

Vergleiche:

Code

$ echo .*

Code

$ echo .[^.]*

Das zweite Pattern passt auf alle Einträge, die mit einem Punkt, gefolgt von einem nicht-Punkt beginnen.

Zitat von for(;;)

Warnung:
Du solltest Dir ausgesprochen sicher sein, im richtigen Verzeichnis zu sein, bevor Du rm -rf .* startest!

Du solltest Dir ausgesprochen sicher sein, den richtigen Befehl zu haben, bevor du jemand anderem dazu rätst, der nach eigener Aussage nicht firm in der shell ist! Oder ihm wenigstens verraten, wie er den Befehl gefahrlos testen kann...

spider-j · 13. Oktober 2015

1.) What Henning said. Und ich möchte noch hinzufügen: den rf Switch mit Wildcards am besten nie empfehlen, wenn man nicht lokal vor dem entsprechenden Rechner sitzt. Es ist in der "Ferndiagnose" nie ausgeschlossen, dass derjenige dann doch noch irgendwelche wichtigen Daten dort liegen hat, auf die das Pattern passt.

2.)

Zitat von for(;;)

In diesen Dateien speichert OSX Metainformationen ab, die es in anderen Dateisystemen als HFS(+) nirgends sonst ablegen kann. Genauso gut könnte ich fragen, wieso mir Windows immer eine thumbs.db in mein Verzeichnis legt, irgendwo müssen diese Betriebssysteme eben Informationen ablegen.

Das BS braucht das eigentlich nicht. Das machen unter Win/OSX einfach nur die Standard-Dateimanager so. Unter Linux ist es meist etwas besser, aber auch hier kann mal "Müll" übrig bleiben, wenn man per GUI-Dateimanager was kopiert und dann nicht richtig auswirft oder Kopierprozesse abbricht oder so. Ich habe mir angewöhnt die ganzen SD-Karten für MMCR/1541U/TC64 lieber per Terminal/CMD zu bearbeiten. Für Terminal-Scheue gibt es auch immer noch den Midnight Commander für alle Betriebssysteme.

3.) Will man auf den geliebten GUI-Dateimanager nicht verzichten, wirkt sauberes Auswerfen/Unmount manchmal auch schon wahre Wunder Zumindest lässt mich der Ausgangspost vermuten, dass es sich bei den ganzen Leer-D64 um nicht finalisierte Zwischenkopien handelt.

for(;;) · 13. Oktober 2015

Zitat von Henning

Quellcode
1
$ echo .[^.]*

Das zweite Pattern passt auf alle Einträge, die mit einem Punkt, gefolgt von einem nicht-Punkt beginnen.

Das ist zweifellos das bessere pattern, weil es von rm nicht verlangt, etwas mitzudenken. Bevor ich mein Posting geschrieben habe, habe ich meinen Befehl allerdings auf meinem eigenem System getestet und es ist mitnichten so, dass rm das eigene Verzeichnis (.) oder gar übergeordnete Verzeichnisse (.. und was danach kommt) mit einschließt:

Code

Nils-Mac-mini:test j$ rm -rf .*
rm: "." and ".." may not be removed
Nils-Mac-mini:test j$

Henning · 13. Oktober 2015

Na gut, dann hätte man wohl im Falle von MacOSX Glück gehabt. Allerdings verhält sich nicht jedes rm so. Auf diversen Systemen tut rm nämlich noch genau das, was man ihm sagt. Auf Linux hat sich rm bis vor ein paar Jahren auch nicht auf solche Weise verweigert. Ich gehe lieber davon aus, dass ein Befehl das tut, was er soll.

Rotzwald · 14. Oktober 2015

Vielen Dank, habe das Procedere soeben angewendet und es hat einwandfrei geklappt.

Code

$ cd /Volumes/Cardname
$ echo .[^.]*
$ rm -rf .[^.]*

Das Kommando

Code

diskutil unmount NAME-DER-SDKARTE

hat zwar folgende Fehlermeldung

Code

Volume C64 on disk2s1 failed to unmount

ausgelöst, die vielen Trashfiles sind aber trotzdem weg.
Ich fasse zusammen: Unsichtbare Dateien unter OSX beginnen mit einem . (Punkt)
Da man gefahr läuft übergeordnete Verzeichisse zu löschen sollte man nur die oben genannte Routine verwenden, da sie Files oder Ordner ausschließt die mit Punkt gefolgt von Punkt (..) beginnen.

Danke ans Forum, es sist nun wirklich viel aufgeräumter und leichter zu benutzen!

Retro Ronny · 14. Oktober 2015

Hallo Rotzwald - kannst du mir das bitte am Samstag am Commodore Stammtisch zeigen?
Danke

for(;;) · 15. Oktober 2015

Sorry, mein Fehler, das musste scheitern, weil Du nicht das Verzeichnis aushängen kannst, in dem Du Dich gerade befindest. Wenn Du mit "cd" vorher in Dein Heimatverzeichnis wechselt (oder eben in irgend ein anderes Verzeichnis) sollte es klappen:

Code

cd
diskutil unmount NAME-DER-SDKARTE

Rotzwald · 15. Oktober 2015

Zitat von Retro Ronny

Hallo Rotzwald - kannst du mir das bitte am Samstag am Commodore Stammtisch zeigen?
Danke

Sicher doch!

neoman · 30. Oktober 2015

Es gibt zum löschen auch dot_clean: https://developer.apple.com/li…ges/man1/dot_clean.1.html

Gesendet von meinem XT1032 mit Tapatalk