Ich habe hier auf einer externen FireWire-Festplatte, die unter anderem auch für Time Machine genutzt wird, im Root-Ordner die Datei .metadata_never_index mittels CLI samt touch angelegt, da Spotlight-Suche für diese HD eh nicht relevant bzw. gewünscht ist.

Allerdings scheint sich 10.5.6 nicht wirklich dafür zu interessieren, es wird dennoch munter indiziert. Ein neuer Bug seit 10.5.6?

Funktioniert's denn bei auch noch unter 10.5.6, wenn man Volumes von der Indizierung ausschließt?

Ich lösche den Index und schalte die Indexierung aus mit:


Ich finde es RICHTIG nervig, daß jedes Medium immer sofort indexiert wird. Die Besitzer der USB-Sticks, die ich öfters mal benutze, sind immer sehr begeistert.

Anstatt dem blöden Spotlight zu sagen, was er nicht indexieren soll, sollte man expliziert sagen können, was man indexiert haben möchte.

exAgrajag
Diese Methode funktioniert aber nur an dem Mac, an dem das Kommando ausgeführt wurde, oder? Wenn man also das entsprechende Volume woanders ansteckt, wird wiederum indiziert oder nicht?

Aber es ist richtig, dass Spotlight nur das indizieren sollte, was man auch konkret vorgibt. Und nicht Ausnahmen definieren.

Wobei Spotlight gerade bei Leopard eh sehr verbesserungswürdig ist. Gegenüber dem Spotlight-UI von Tiger war das geradezu eine Rolle rückwärts.

Sozusagen von Version 1.0 bei Tiger zurück zu einer 0.5 bei Leopard. Dass es nun einen Tick schneller ist (einen Tick, nicht mehr), davon kann ich mir rein gar nichts kaufen bei dem scheiß Spotlight-UI nun.

Ich hab es ehrlich gesagt noch nicht ausprobiert, aber wenn ich mich nicht irre, wird die Information in dem Spotlight-Index-Ordner der jeweiligen Partition geschrieben die Platte ist überall vom Indexieren ausgeschlossen. Aber alle angaben ohne Gewähr. Aber das kann man ja leicht prüfen.

Mich nervt vor allem, daß, wenn man im Finder sucht, sich nicht gemerkt wird, daß ich im aktuellen Ordner nach DATEIEN suchen will. Im Finder will NUR nach Dateien suchen, fast nie nach Inhalten suchen.

Der Mike,
exAgrajag:

Wenn per touch eine leer .metadata_never_index Datei im /-Verzeichnis des betreffenden Volumes abgelegt wird, dann ist die da dann eben abgelegt. Auch wenn das Volume woanders angesteckt wird.
Bei mir hat das vor wenigen Wochen wunderbar funktioniert, Spotlight davon abzuhalten, das betreffende Volume zu indizieren bzw. Spotlight diesbzgl. erstmal in die Schranken zu weisen und stillzuhalten.

@sierkb: Ja, aber wer will das denn bei jedem mistigen USB-Stick machen, den man in die Hand gedrückt bekommt? Außerdem kann man darauf wetten, daß die Datei (ebenso Dateien wie .DS_Store oder Ordner wie .Trashes) gelöscht werden. Beim nächsten mal will Spotlight also wieder durch den Stick ziehen... *grummel*

Ich kenne jedenfalls so einige, die immer genervt sind, wenn deren Stick in einen Mac gesteckt werden soll.

exAgrajag
Mir geht's hier in erster Linie um meine Volumes. Und da will ich neben ".metadata_never_index" freilich auch nicht auf Metadaten-Informationen, wie sie in .DS_Store-Dateien abgelegt sind (da werden die Ordnereinstellungen gesichert), verzichten, gleichfalls bei Netzwerk-Volumes.

Aber Du hast da Recht, dass Apple für beides auch eine Option ins GUI implementieren sollte. Der Ausschluss via Spotlight-Kontrollfeld ist da keine sinnvolle Lösung, was Nicht-Indizierung angeht.

mdutil jedenfalls hilft mir da auch nicht weiter, da ich das dann halt auf all meinen Macs mit allen Wechselvolumes separat einstellen müsste. Und das ist für mich dann recht sinnfrei.

Edit (Zeit war zu kurz):

exAgrajag
Mir geht's hier in erster Linie um meine Volumes. Und da will ich neben ".metadata_never_index" freilich auch nicht auf Metadaten-Informationen, wie sie in .DS_Store-Dateien abgelegt sind (da werden die Ordnereinstellungen gesichert), verzichten, gleichfalls bei Netzwerk-Volumes.

Aber Du hast da Recht, dass Apple für beides auch eine Option ins GUI implementieren sollte *. Der Ausschluss via Spotlight-Kontrollfeld ist da keine sinnvolle bzw. Mac-like Lösung, was Nicht-Indizierung angeht.

mdutil jedenfalls hilft mir da auch nicht weiter, da ich das dann halt auf all meinen Macs mit allen Wechselvolumes separat einstellen müsste. Und das ist für mich dann sowieso recht sinnfrei.

* Das Problem ist hierbei aber: Wo soll diese Information abgelegt werden, vor allem bei Primitivdateisystemen wie FAT32, wie sie etwa bei USB-Sticks üblich sind?

Da finde ich aktuell halt .metadata_never_index im Root-Ordner noch die praktikabelste Lösung. Eine Option dazu im Info-Dialog zu einem Volume wäre fein, damit man dazu nicht das Terminal bemühen muss (ebenso bei den Metadaten-Informationen, also z.B. den .DS_Store-Dateien). Ähnlich wie beim Button "Eigentümer auf diesem Volume ignorieren" halt. Aber bitte noch vor Snow Leopard...

sierkb
Du schreibst, dass es bei Dir bis vor wenigen Wochen funktioniert hat. Also funktioniert es seit 10.5.6 z.B. nicht mehr?

Ich habe das nämlich leider erst gestern bewusst beobachten können (schließlich ging ich ja davon aus, dass die entsprechenden Volumes nicht indiziert werden, erst das Spotlight-Icon in der Menüleiste fiel mir da beim neuen USB-Stick ins Auge, welcher natürlich sofort mit .metadata_never_index im Root-Ordner versehen wurde, Spotlight jedoch dennoch munter mit der Indizierung begann). Aber meine Vermutung ist ein neuer Bug in 10.5.6 bzw. exakt seit dem Update.

Sehr wichtig ist Nicht-Indizierung via .metadata_never_index übrigens bei DVD-RAMs. Denn ansonsten hat Leopard ganz extreme Performance-Probleme damit.

(DVD-RAM nutze ich vor allem wegen der ungleich höheren Datensicherheit gegenüber DVD+/-R(W) oder Festplatten für alles, was Langzeitdatensicherung angeht, also fürs Archiv.)

Ach, das oben war Unsinn: Hatte das mit der "Dennoch-Indizierung" nicht beim neuen USB-Stick bemerkt, sondern bei der neuen FireWire-HD (mit HFS+ initialisiert).

Klar, worum denn sonst?!? Partitionen == Volumes
Diese Information landet auf der jeweiligen Partition. Du musst das also, genau so wie das Anlegen der Datei, lediglich pro Parition machen. Das akzeptiert dann JEDER Rechner.

Auf der Partition befindet sich dann einfach der Ordner .Spotlight-V100. Dadrin dürfte sich der entsprechende Hinweis (do not index) befinden.

Oh ja, da hatte mich das ja so RICHTIG angeko... Naja, ich benutze nur 2 DVD-Medien für meine Backups (mein Home-Ordner). Meine wichtigsten Daten befinden sich dann auf DVD-RAM, DVD-ROM und Backup-Platte – irgendwas wird dann im Zweifel wohl überleben.

OT: Du benutzt nicht zufällig WriteUDF ?

exAgrajag
OK, muss ich mal ausprobieren. Nur: Wo ist da der Unterschied zwischen "mdutil -i off -E /Volumes/blablubb" und ".metadata_never_index"? Zwei Lösungen bzw. "Implementierungen" mit absolut gleichem Ergebnis (bis 10.5.5 )? Was hat sich Apple dabei gedacht?

Nein, UDF nutze ich nicht bei DVD-RAM. HFS+ ist OK für mich, auch bei DVD-RAMs fürs Archiv.

Sichere da allerdings keine Homeordner, sondern wirklich wichtige Daten wie Fotos und relevante Dokumente (Musik ist etwa nicht relevant, weil halt absolut redundant - Ausnahmen: meine Vinyl-Sammlung, aber das ist analog recht sicher, und die selbst gesungene "Musik" bzw. auf der Triangel gespielte ). Allerdings zusätzlich freilich redundant, die Fotos und die Dokumente. (Nein, damit meine ich keine Sicherung via Time Machine auf HD. Das ist zwar fein, allerdings absolut kein Backup relevanter Daten, sondern dient alleine einer schnellen Systemwiederherstellung bei einem Ausfall des Bootvolume. Was wieder was ganz anderes als ein Backup ist. )

man mdutil.

Mit ein wenig Nachdenken kommst Du selber drauf, dass es da Unterschiede gibt. Bitte schau mal in der Manpage nach, wozu die Parameter -i off und -E genau sind. Wobei -E /Volumes/blablubb eher extra betrachtet werden sollte, ums klar zu sehen.
Bzgl. .metadata_never_index solltest Du Dir folgendes Scenario mal durch den Kopf gehen lassen, wo das evtl. letzte Rettung sein könnte: Spotlight-Index zerschossen, Platte evtl. defekt, mdutil rattert gnadenlos los und lähmt das gesamte System. Nix geht mehr, selbst Terminal-Zugriff nicht mehr, und auch im Single-User-Modus kannst Du nichts mehr ausrichten mit mdutil. Die einzige Methode, die Spotlight-Indizierung hart zu stoppen bzw. zu unterbinden ist es, das betreffende Volume von der Installations-DVD aus zu mounten und .metadata_never_index in den Root-Ordner / zu schreiben. So zum Beispiel bei mir geschehen. Hatte keine Möglichkeit, Spotlight irgendwie in seine Grenzen zu weisen, nix ging mehr. Das war der letzte Ausweg, Ruhe ins Schiff zu bekommen und irgendwelche Notfall-Dinge zu tätigen.
Unix-Philosophie bedeutet: viele Wege führen nach Rom. Manchmal ist Redundanz in den Funktionalitäten überlebenswichtig und äußerst hilfreich.

sierkb
OK, aber was von beiden Lösungen hälst Du erst mal für die "standardmäßig bessere"? Sofern .metadata_never_index vielleicht mal wieder mit 10.5.7 funktioniert, aber wie man Apple seit Leopard kennt, hat man es da seit 10.5.0 nicht mehr so sehr, Bugs auch mal wieder zu beheben, siehe Alias-Bug (überhaupt nicht mehr funktionierende Auswertung von .DS_Store-Dateien beim ersten Öffnen nach einem Neustart (oder einer Neuanmeldung eines beliebigen User-Accounts) von einem Ordner-Alias - etwas, was unter X mal von der Public Beta im Jahre 2000 bis einschließlich 10.4.11 funktioniert hat (geschweige denn sogar unter System 7.x.x bis Mac OS 9.2.2), aber seit 10.5.0 bis einschließlich 10.5.6 nicht mehr - und der Bug wurde mir von Apple höchstselbst per E-Mail - wurde von mir via Bug-Reporter-Account gemeldet - bereits im November als Apple bekannt bestätigt, gleicher Bug übrigens beim ersten Öffnen einer iDisk im Finder)...

Und nochmals meine Frage an Dich: Konntest Du dieses "Fehlverhalten" des "Nicht-Indizierens" via .metadata_never_index auch erst seit 10.5.6 beobachten?

Und ist das tatsächlich so, dass man über die "mdutil-Methode" dann auch noch nachträglich den bereits erstellten Index via Terminal löschen muss und das Mac OS X nicht automatisch macht, wenn man die Indizierung via mdutil abschaltet?

AFAIR war es via .metadata_never_index so, dass der Index dann auch spätestens bei nächsten "Indizierungsversuch" von Leopard gelöscht wurde, wie's ja auch sein sollte.

Ich habe dieses "Fehlverhalten", wie Du es anscheinend beobachtet hast, bisher nicht beobachtet. Unter 10.5.5 hat's jedenfalls geklappt. Wie es unter 10.5.6 aussieht, habe ich bisher noch nicht ausprobiert.

Zu allem Weiteren befrage am besten mal _mäuschen, der hat da die längere Praxis drin, von ihm hatte ich diesen Tipp auch, als ich vor einigen Wochen durch eine plötzlich alle System-Ressourcen verbrauchende Spotlight-Indizierung ein nicht mehr benutzbares System erhielt. Der Tipp mit .metadata_never_index war sozusagen erstmal eine Notbremse, die ich ziehen musste, um überhaupt noch irgendwas (und seien es rudimentäre Unix-Befehle im Single-User-Modus) absetzen zu können. Mein System habe ich danach völlig neu aufgesetzt.
Zu Vor- und Nachteilen bzgl. .metadata_never_index versus mdutil befrage deshalb mal lieber _mäuschen.
Ich habe jedenfalls seitdem gehörigen Respekt vor Spotlight und mdutil und bin froh, wenn beide ihren Dienst unbemerkt im Hintergrund tun. Denn wenn sie mal aus dem Takt geraten, dann können sie u.U. das gesamte System in den Orkus reißen (bei mir war aus irgendwelchen Gründen (evtl. auch durch mein Zutun aufgrund des Herumelaborierens um den Spotlight-Index) nachher das Datei-Journaling völlig zerschossen, das System dann völlig dahin.
Große Loblieder singe ich deshalb nicht auf Spotlight bzw. dessen Indizierung, weil wie bei mir geschehen, das System bis zur völligen Lähmung geraten kann, wenn diese Indizierung sich mal alle Ressourcen gekrallt hat und/oder irgendwo bei irgendeiner Datei auf einmal hängt oder Probleme macht.
Bei mir ist wohl einer der seltenen Fälle eingetreten (wenn ich alle Informationen, die ich seitdem im WWW dazu gesammelt habe, subsummiere), die wohl der Wahrscheinlichkeit nach äußerst selten bis nie eintreten. Blöd, aber wohl leider wahr.
Seitdem ich diese leidvolle Erfahrung habe machen müssen, bin ich noch skeptischer MacOSX Leopard gegenüber, was die Stabilität angeht. Unter Linux habe ich so einen Fall in gut 12 Jahren bisher nicht gehabt, dass das System sich selber ins totale Nirvana geschossen hat aufgrund eines regulären Deamons, der einfach nur im Hintergrund still und leise seine Arbeit tun soll. Jeder, der hier bei MTN meint, ein Loblied auf die Überlegenheit von MacOSX gegenüber einem Linux-System singen zu müssen, dem kann ich diesen speziellen Fall unter die Nase halten, dass das Etikett halbgare "Frickel-Software" in diesem Fall wohl eher an MacOSX geht als an Linux...

Zu Deinen ständigen immer wiederkehrenden Bug-Tiraden bzgl. Alias-Bug und Konsorten nur soviel: wir haben es begriffen, Du musst es nicht jedesmal aufs Neue wie auf dem Silbertablett oder wie eine Monstranz vor Dir hertragen... Immer wieder dasselbe, wenn Du davon anfängst. Wir wissen es inzwischen! Alles weitere nervt einfach nur... Sorry, musste mal gesagt werden.

sierkb
Ja, bis zu 10.5.5 konnte ich das auch nicht beobachten, wie bereits angemerkt.

Und nein, das mit dem Alias-Bug ist wieder was ganz anderes als eine "Monstranz vor sich herzutragen". Ich muss das schließlich wissen, ich war früher mal Ministrant!

Wie dem auch sei: Ich merke das deshalb immer wieder an, weil es halt ein extrem nerviger Bug ist, der von Apple nun schon seit bald 1,5 Jahre nicht behoben worden ist. Und deshalb hoffe ich nicht, dass das hier nun wieder mal der Fall sein wird (ich wette zu 90 %, dass .metadata_never_index auch bei 10.5.7 "ignoriert" werden wird, Bug-Reporter-Meldung ist bereits abgesetzt und Apple wird sich wohl bald äußern). Jedenfalls ist es so, wenn Bugs "im Gespräch" bleiben, diese auch weiteren Usern auffallen - und diese dann hoffentlich ebenfalls an Apple via Apples Bug Reporter melden. Denn für Snow Leopard dürfte Apple dann gar keine Zeit mehr haben. Hoffentlich.

Und zu Linux sage ich jetzt mal gar nichts. Was ich da schon seit MkLinux 1996 erlebt habe... (Ist hier eh off topic.)

Aber dieses oder jenes OS ist da für mich als "Referenz" sowieso nicht hilfreich (hui, was nervt es mich schon, wenn jemand allen Ernstes noch mit Windows als "Vergleichsmaßstab" kommt), da ich halt mit Mac OS X gerne arbeiten möchte (und ich habe schon vieles benutzt, sei es BeOS, sei es AmigaOS, sei es CP/M uswusf.). Dazu gerne noch mit weniger Bugs als vor Leopard. Und das will bei Mac OS X schon was heißen.

Der Mike:

CP/M: damit habe ich Ende der 80er auch angefangen. Aus Interesse und Trotz gegen das damals zeitgleich aufkommende DOS. Um etwas auf meinem CPC-Homecomputer zu benutzen, was Grundlage für DOS war bzw. um die Arbeitsweise von DOS dann wie im Schlaf zu verstehen.
Und BeOS hatte ich eine zeitlang auch auf meinem damals Tri-Boot-System (Win, Linux, BeOS). Darwin/386 gab's auch damals schon, scheiterte aber bzgl. Treibern an meiner Hardware. Sonst wäre es als 4. Betriebssystem auf meiner damaligen HD gelandet.
Das nur mal so nebenbei und OT.

Bzgl. Linux: ich arbeite und entwickle da teilweise seit mehreren Jahren drauf. Auf dem Server will ich es nicht missen und auch gegen nichts eingetauscht haben. Bevor ich mich MacOSX zugewendet habe, habe ich fast nur unter Linux gearbeitet. Zu MKLinux kann ich nix sagen, bei mir lief schon immer auf allen möglichen Rechnern die i386/i586-Version, mit Linux/PPC habe ich keine Erfahrung. Zum Mac bin ich bewusst gewechselt, als Apple zur Intel-Version geswitcht ist. Ich wollte das bewusst abpassen, weil ich die Abkehr von PPC-Plattform bzw. die Querelen um den PPC jahrlang beobachtet habe. Der Wechsel zu Intel erschien mir nur ein logischer und folgerichtiger, ja unausweichlicher Schritt. Da ich unter Linux Binaries erstelle, die nachher auch in der openSUSE Distribution erscheinen, und ich Linux unbedingt auch auf der Mac-Hardware laufen lassen wollte, kam für mich PPC nie ernsthaft in Frage, ich wollte bei Intel bleiben.

Zum Studium



Funktioniert doch wunderbar und ohne Fehler


Wenn Spotlight trotzdem was findet, heisst das noch lange nicht,
dass indiziert wurde.

sierkb
Komme auch vom CPC (und vom Amiga ). Habe hier sogar noch einen praktisch farbrikneuen Amstrad CPC 464 stehen (inkl. Original-Monitor Amstrad CTM 644), welcher wohl bislang nicht mal drei h betrieben wurde.

(War aus einer Lagerauflösung eines ehemaligen CPC-Händlers. Der Rechner dürfte so Ende der 1980er hergestellt worden sein. Man sieht aber, dass er praktisch "fabrikneu" ist, weil ohne jedwede Gebrauchtsspur.)

BeOS habe ich nur auf PowerPC-Hardware benutzt (ist da gerannt "wie Sau", war damals auf einem PowerPC 604e), Linux auf dem Desktop zumindest bislang ebenso ausschließlich auf PowerPC (von virtuellen Maschinen abgesehen, da tut's auch x86).

_mäuschen
Interessant. Allerdings gibt bei mir auf meiner FireWire-HD mdutil -i on /Volumes/<Volumename> "Indexing enabled." aus, obwohl eine Datei namens .metadata_never_index via touch sofort nach der Initialisierung (HFS+ ohne Journal) angelegt wurde. Eine Idee, woran das liegen könnte?

Und wie ist das bei 10.5.6 aktuell eigentlich bei USB-Sticks, die mit FAT32 formatiert sind? Werden die ebenfalls automatisch indiziert? (Spotlight macht ja bestimmte Ausnahmen, etwa bei bestimmten AFP-Servern, wohl insbesondere solchen, die auf netatalk basieren und nur AFP 3.1 oder weniger können.)

_mäuschen
Also: Ich wollte es jetzt mal genauer wissen, weil's bei Dir ja funktioniert.

Habe das Volumes (nach Sicherung des relevanten Inhaltes via Drag & Drop im Finder) mal komplett neu initialisiert. Wiederum HFS+ ohne Journal sowie mit Apple-Partitionstabelle (und ohne Mac OS 9-Treiber), da hier mehr PowerPC als Intel-Macs stehen. (War alles exakt so wie bei der allerersten Initialisierung, da ich alle meine FireWire-Festplatten so formatiere.)

Dann sofort die Datei .metadata_never_index angelegt und via mdutil -i on /Volumes/<Volumename> "nachgefragt", ob's denn diesmal (eventuell) "angekommen" ist. Und siehe da: Jetzt "Indexing and searching disabled." im CLI.

OK, also an was lag es?

Ich habe das entsprechende Volume vor wenigen Tagen via Festplatten-Dienstprogramm (also mittels GUI für asr) gesichert, da ich zwischendurch eine andere Verwendung dafür hatte. Rücksicherung war gleichermaßen.

Ein Bug bei asr beim Sichern oder Rücksichern also nun, so dass dann .metadata_never_index ignoriert wird, obwohl vorhanden?

Argh!

Zu früh gefreut!

Ich nutze diese HD auch für Time Machine für einen bestimmten Mac (ansonsten sichere ich via AFP). Als ich Time Machine aktiviert hatte, kommt bei mdutil -i on /Volumes/<Volumename> wiederum das im CLI: "Indexing enabled.". Wird hier also Spotlight bei einem TM-Volume automatisch "zwangsweise" aktiviert und .metadata_never_index generisch ignoriert?

Benötigt TM denn unbedingt eine Spotlight-Indizierung auf der "Sicherungs-HD", um überhaupt funktionieren zu können? Wenn ja, warum? Ich lerne gerne immer was dazu!

(Und würde mich freuen, wenn's denn wenigstens diesmal kein Leopard-Bug wäre. )

It will contain its own Spotlight index.

_mäuschen
Das TM-Sparsebundle selbst. Aber warum wird dann offenbar gleich die gesamte HD indiziert (bzw. die Indizierung trotz .metadata_never_index aktiviert), wenn man TM für dieses Volume als Sicherungsort wählt?

Denn wenn man das Volume wieder im TM-Kontrollfeld abwählt: "Indexing and searching disabled."

Es ist kein Leopard-Bug: es werden zwei Indizes angelegt

Einer für TM himself und einer (wenn nicht ausgesphärt) für die ordinary SLsuche

_mäuschen: sei doch nicht so gemein zu Mikey-Baby. Er ist so scharf darauf, Bugs zu entdecken, dass er jetzt schwer enttäuscht sein wird.
Mikey-Baby, erzähl uns doch mal von deinem schönen Bug! Der mit dem Alias. Der Bugus Mikus! Der wichtigste Bug der Welt!

Nur so am Rande: Den Indexing-Status einer Partition erfragt man mit
Übrigens für alle gleichzeitig mit

@bimden: Was soll das denn bitte jetzt?

exAgrajag
mdutil -s /Volumes/<(TM-)Volumename> ergibt das: "Indexing enabled."

Trotz der bewussten Datei im Root-Ordner.

Zum Büblein (oder was auch immer) oben: Ist wohl die Pubertät.

_mäuschen
Ja, aber bei einer "TM-Aktivierung" dann wohl gleich zweifach. Im TM-Sparsebundle selbst (ist ja vollkommen OK und nachvollziehbnar) und für das TM-Volume an sich (trotz der bewussten Datei ). Nur warum?

Wähle ich TM für das TM-Backup-Volume ab, wird auch kein Index (für das Volume an sich) mehr angelegt: "Indexing and searching disabled."

Könnt ihr das reproduzieren?