zu dem spektakulären Artikelbild fällt mir doch glatt die aktuelle Folge von ZDF Sketch History ein:

MacTechNews
Hallo. Habt Ihr den Artikel so irgendwo übernommen oder komplett selbst verfasst? Denn ich würde diese Anleitung ein wenig detaillierter verfassen. Alle Leute, die unbedarft ihren Mac nun überprüfen wollen, werden sich wundern, warum sudo dann, wenn der Mac vernünftig eingerichtet wurde, erstmal nicht geht: Also login mit admin-Rechten ist erforderlich. Und da direkt nach Abfrage des Kennwortes der Befehl, also find, ausgeführt wird, darf man sich auch nicht wundern, wenn das dann erstmal sehr lange dauert.
Und: Habt Ihr mal über die AppleScript-Serie nachgedacht? Oder lest ihr hier die Kommentare nicht? Soll ich mal woanders hinschreiben?

Na gottseidank, es werden noch Dinge gemeldet, die den Namen diese Magazins rechfertigen. Bei wichtigen Meldungen über neue Smileys von Apple etc. sind mir Zweifel gekommen.

Ich finde die Meldung war perfekt. Man sollte auch nicht alle Leute für dämlich halten. Ich habe es sofort verstanden und andere können das auch. Ausserdem kann man nicht jede Anleitung bis ins Kleinste beschreiben, das würde zu weit führen.

Macmissionar "vernünftig eingerichtet". Du möchtest uns als weis machen, dass die Mac-Nutzer, die verstanden haben, dass es besser ist dem "Alltagsbenutzeraccount" die Admin-Rechte wegzunehmen und einen separaten Admin-Account anzulegen, überfordert sind, wenn "sudo" nicht sofort funktioniert?
Mein Bauchgefühl sagt mir, dass 90% aller Macs so verwendet werden wie sie ausgeliefert werden, bzw. wie die Vorgaben sind. Und dabei hat der Nutzer eben Admin-Rechte und kann "sudo" verwenden.
Der Artikel ist absolut ok so.

Gibt es denn noch User, die das vergessen?
Dem Anschein nach ...

Macmissionar
Der Artikel ist natürlich selbst verfasst. Verstehe ich dich richtig, dass dir ein Hinweis auf das sudo-Login fehlt?

Was ich nicht kapiere - ich bekomm dann auch solche Meldungen:

Ich hab find doch nicht beauftragt danach zu suchen? Für die gesuchten Dateinamen hingegen gibt es gar keine Ansage.

find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory

Reicht das schon? oder kommt da noch mehr?
Tut sich irgendwie seit ein paar Minuten nichts mehr, der Lüfter bläst aber wie verrückt.

Danke!

edit: OK - es geht noch weiter. Da kommt noch mehr.
Merkt man irgendwann dass der Prozess abgeschlossen ist?

Daran dass da wieder ein $ steht und auf deine Eingaben wartet.

Standardfehler unterdrücken:

Danke!!

puenktchen
Doch, hast Du mit dem Befehl, denn das / steht für alles ab Mountpunkt der Platte, ergo gesamte Platte.
UPDATE: Gleich 3 Fragen zum laufenden Prozeß und dem Warten auf das Ende ... vielleicht sollte da doch was ergänzt werden, Marxist-Fan?

Übrigens bei mir auf einem 2,8 GHz iMac 1 TB Fusion Drive hat das jetzt ca. 20 Minuten gelaufen und er hat die Dateien gar nicht gefunden; kann also auch keine Checksumme erstellen. Hm.

Mir ist schon klar dass ich die ganze Platte durchsuche. Aber doch nach Dateien namens afpscan bzw macsvc. Wieso meldet mir find dann dass es was ganz anderes nicht finden konnte? Fehler in der Hierarchie des Dateisystems? Verwaiste Einträge?

Hallo Pünktchen, ich glaube, daß das einfach ein Standardfehler bzw. eine Warnung von find ist, da er dieses Verzeichnis nicht durchsuchen kann (keine Rechte hat und daher diese Meldung ausgibt, Not a directory). Er versucht also auch dort, etwas zu finden.
Ist es denn korrekt, daß hier keiner die beiden Dateien findet? Meine Suche nach der zweiten, afpscan, läuft immer noch, aber bisher auch da nix gefunden.

Ja bei mir findet er nichts.

Es gibt ein Verzeichnis /dev/fd, allerdings sind da nur die Dateien 0,1,2,3,4,5 drin. Aber ich bekomm auch Fehler für Ordner die existieren und auf die ich Zugriff habe. Auf dem Server übrigens - braucht dein Computer vielleicht solange weil er auch Netzwerkvolumes mit durchsucht? Die sind bei / natürlich alle mit dabei.

Naja vier Fehlermeldungen bei Hunderttausenden Ordnern und Dateien sind ja gerade noch zu ertragen.

IceHouse
Vielen Dank für die hilfreiche Ergänzung! Ich habe den Artikel entsprechend angepasst.

Oooops, hier geht ja einiges durcheinander …
Seltsame Frage – diese beiden Dateien sind Viren. Wer eine davon findet, ist folglich von diesem Virus befallen.

Deine Frage lässt sich also paraphrasieren als:

Ist es denn korrekt, daß hier keiner von einem Virus befallen ist?

Und diese Frage verstehe ich irgendwie nicht ganz …
Ich bin mir sehr sicher, dass in /dev/fd/ bei Dir keine Datei namens puenktchen zu finden war – sondern nur Dateien, die mit Ziffern durchnummeriert sind. Falls doch, hättest Du gaaaaanz andere Probleme …

/dev/fd/ ist kein normaler Ordner, auch wenn das so aussehen mag. Vielmehr steigt man hier tief, tief in die Interna von Unix hinab.

Grob vereinfacht gesagt: Unix braucht für die Kommunikation zwischen verschiedenen Prozessen (= verschiedenen Unix-Programmen) temporäre „Zwischenspeicher“ – so ähnlich, wie wenn Ihr in einem Programm eine Datei sichert, um sie dann in einem anderen Programm öffnen und dort mit den Daten weiterarbeiten zu können.

Da eine der Grundpointen von Unix ist, alles auf möglichst wenige vereinheitlichte Grundprinzipien zurückzuführen, werden diese „Zwischenspeicher“ wie Dateien behandelt, auch wenn es eigentlich keine sind. Und diese „Dateien“, die keine sind, tauchen im Dateisystem alle in einem ganz speziellen Ordner auf, nämlich eben /dev/fd/ – dev steht für Devices = Geräte = „Unix-Bausteine“, fd für File Descriptors = Dateibezeichner.

Diese Dateibezeichner sind einfach aufeinanderfolgende Ziffern. Die Ziffern 0 bis 2 sind fest vergeben und daher auch immer vorhanden: 0 ist die Eingabe im aktiven Terminal, 1 die Ausgabe und 2 die Ausgabe für Fehlermeldungen. (Das erklärt auch, warum der Befehl 2 > /dev/null dafür sorgt, dass man nicht mit Fehlermeldungen behelligt wird: weil eben der Dateibezeichner für Fehlermeldungen auf das „Gerät“ /dev/null umgeleitet wird, was, wie sich unschwer erraten lässt, für sowas wie einen „Unix-Papierkorb“ steht).

Alle Ziffern größer als 2 werden von Unix ad hoc vergeben und auch wieder entfernt.

Ihr als Anwender müsst Euch eigentlich nur merken:

Alles innerhalb von /dev/fd/ sieht nur aus wie eine Datei, ist aber keine, und kann/sollte von Euch geflissentlich ignoriert werden.

find meldet Dir ja auch nicht, dass es was gefunden hätte, sondern einen Fehler (was sich eben deshalb mit 2 > /dev/null unterdrücken lässt).

Momentan lag in Deinem /dev/fd/-Ordner zufällig gerade ein Dateibezeichner, der einen Ordner repräsentiert (Ordner sind für Unix – wiederum das Prinzip der wenigen vereinheitlichten Grundprinzipien – auch nur Dateien, nämlich solche, die den Ordnerinhalt auflisten). Deswegen will find diesen Ordner untersuchen, kann es aber nicht, weil es sich eben um einen Dateibezeichner handelt. Und deswegen meldet Dir find, dass es hier ein Problem gibt.
Dann freu Dich doch – andernfalls wäre Dein Mac von einem Virus befallen.

Weia

Danke für den kleinen Unix Exkurs. Wirklich interessant 👍🏼
Das klärt auf jeden Fall einiges

Weia
Es ist kein Virus, sondern ein Trojaner!

Ja, Du hast Recht, ich war hier nicht sehr präzise und habe Virus als generisches Synonym für Computerfiesling jeglicher Art gebraucht.

Als mildernden Umstand kann ich nur anführen, dass ich damit nicht allein bin:

MBP 2,2 GHz i7 mit 10.6.8 brauchte 1 Minute (ohne Fund).

Und was willst Du uns damit sagen?

Wie lange find braucht, hängt im Wesentlichen von der Anzahl der Dateien auf der Festplatte ab, die find durchsuchen soll. Und natürlich geht’s bei einer SSD schneller. Betriebssystem-Version und Prozessorgeschwindigkeit sind demgegenüber komplett egal. Die Festplattengröße auch, wenn man davon absieht, dass sich auf einer großen Festplatte natürlich theoretisch mehr Dateien befinden könnten.