Kann in Mac OS X eine Suchdatenbank für ein Netzwerk-Volume erstellt werden?

740
tom stratton

Ich muss in der Lage sein, Millionen von Dateien auf einem Netzwerk-Volume schnell zu durchsuchen. Statt direkt zu suchen, möchte ich die Informationen in einer Datenbank nachschlagen.

Anstatt selbst zu "rollen", scheint es sinnvoll, eine Datenbank zu verwenden locateoder mlocatezu erstellen, aber ich war nicht in der Lage, ein mit einem AFP-Netzwerk verbundenes Volume (oder SMB für diese Angelegenheit) zu erhalten locateoder mlocatezu bearbeiten.

Hat jemand einen Vorschlag? Ich habe die locate.rcDatei in allen möglichen Kombinationen geändert, aber ich vermute, dass AFP ro SMB für die FILESYSTEMS-Linie nicht akzeptabel ist.

FILESYSTEMS="hfs ufs afp" 

Ich habe NFS ausprobiert. Ich habe keinen Zugriff auf den Server, um ihn so einrichten zu können, dass er Verbindungen von einem Mac akzeptiert (es scheint, dass Sie "unsicher" als eine der Optionen für die Domäne festlegen müssen).

0
Haben Sie in Betracht gezogen, stattdessen "mdfind" (Ie Spotlight) zu verwenden? Asmus vor 9 Jahren 0

2 Antworten auf die Frage

1
keen

Es stellt sich heraus, dass es möglich ist, dass locate.updatedb andere Dateisysteme indexiert, einschließlich des Netzwerks.
Der Haken ist, dass der Stamm des Dateisystems (und der Baum bis hin zu dem Inhalt, den Sie indizieren möchten) für Benutzer / Gruppe "nobody" lesbar sein muss.

Sie waren mit /etc/locate.rc auf dem richtigen Weg

Im Anschluss fand ich heraus, dass /usr/libexec/locate.updatedb nur find verwendet, um den Index zu erstellen.
Es durchläuft die Einträge in /etc/locate.rc FILESYSTEMS (zumindest in 10.6 ist dies standardmäßig nur hfs, wenn nicht gesetzt).

Die Manpage von find schlägt die Verwendung von "sysctl vfs" vor, um herauszufinden, was auf Ihrem Computer gültig ist. In meinem Fall:

sysctl vfs|grep mounted vfs.nfs has 1 mounted instance vfs.hfs has 3 mounted instances vfs.autofs has 3 mounted instances vfs.afpfs has 4 mounted instances 

Einige schnelle Tests, um dies zu bestätigen:

prowler:~%% mount |grep Volumes/keen afp_1I6KyU4igzg00Q0vsj4E2G0H-1.2f0004fb on /Volumes/keen (afpfs, nodev, nosuid, mounted by keen) prowler:~%% touch /Volumes/keen/test-afpfs prowler:~%% find /Volumes/keen/ -name test-afpfs -fstype afpfs prowler:~%% find /Volumes/keen/test-afpfs -name test-afpfs -fstype afpfs /Volumes/keen/test-afpfs prowler:~%% find /Volumes/keen/test-afpfs -name test-afpfs -fstype hfs prowler:~%%  

Für 10.6 ist afpfs für ein in AFP eingehängtes Dateisystem mindestens richtig.

Nun zum Scheitern für afpfs.

Wenn OSX (10.6) den AFP-Datenträger (gemountet über ein Anmeldeelement oder über Finder -> Go -> Verbinden mit dem Server - die herkömmlichen OSX-Mechanismen für AFP) einbindet, hängt es vom Benutzer als lesbar:

prowler:/Volumes/keen%% ls -ld /Volumes/keen drwx------ 6 keen keen 264 Dec 13 12:45 /Volumes/keen/ 

und der Versuch, dies manuell zu korrigieren, schlägt fehl:

prowler:/Volumes/keen%% sudo chmod a+rx /Volumes/keen prowler:/Volumes/keen%% ls -ld /Volumes/keen drwx------ 6 keen keen 264 Dec 13 12:52 /Volumes/keen/ 

Ich habe noch keine Problemumgehung gefunden (ich habe keine Autofaks ausprobiert, da diese Methode bei jeder OSX-Version in der Regel fehlerhaft ist ...).

HFS-Volumes (und vermutlich auch HFS + usw.), die gemountet werden, haben weder dieses Problem noch NFS-Volumes, die über das Festplatten-Dienstprogramm -> NFS-Mounts (10.6) geladen werden.

prowler:~%% mount |grep nfs murf:/backups on /Users/keen/backups (nfs, nodev, nosuid, automounted, nobrowse) prowler:~%% ls -ld /Users/keen/backups drwxrwxrwx 33 root wheel 2048 Dec 13 03:05 /Users/keen/backups/ 

Ich habe dies entdeckt, als ich versuchte, die Indexierung nur des afp-Mount zu testen:

prowler:/Volumes/keen%% grep FILESYSTE /etc/locate.rc  FILESYSTEMS="afpfs"  prowler:/Volumes/keen%% sudo /usr/libexec/locate.updatedbshell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied shell-init: error retrieving current directory: getcwd: cannot access parent directories: Permission denied find: .: Permission denied 

Beim Ausführen mit $ PWD außerhalb des afp-Mounts war dieser Fehler nicht aufgetreten:

prowler:~%% sudo /usr/libexec/locate.updatedb prowler:~%%  

hatte aber auch keine Ergebnisse:

prowler:~%% locate test-afpfs prowler:~%%  

Also die kurze Antwort, wie ich sie bisher gefunden habe - JA! Sie können locate finden, um Netzwerkvolumes unter OSX zu indizieren. NEIN, Sie können kein afp-Netzwerkvolume indizieren.

Ich hatte keine Zeit, um das zu überprüfen, aber es durchzulesen, scheint mir die beste Lösung zu sein, daher akzeptiere ich dies. FWIW, um mein Problem zu lösen, habe ich mlocate direkt auf dem NAS-Server installiert und dann die Datenbank auf dem freigegebenen Datenträger verfügbar gemacht, sodass die Datenbank direkt grep werden kann. tom stratton vor 9 Jahren 0
ha, schöner Trick! Ich ging die Run-as-root-Route für den Moment ... natürlich mit 6T zum Indexieren zwischen den nfs- und afp-Mounts, das hat eine Weile gedauert! Ein anderer Weg wäre, sie zweimal zu mounten - einmal nfs für locate und einmal afp für osx-friendlyity, nehme ich an. keen vor 9 Jahren 0
0
AbsoluteƵERØ

Wenn Sie also versuchen, Millionen von Dateien zu durchsuchen, möchten Sie wahrscheinlich etwas wie grep über die Befehlszeile verwenden. Sie würden über / Volumes / Freigabename auf die Freigabe zugreifen (vorausgesetzt, Sie haben entweder über SMB oder über AFP eine Verbindung hergestellt).

#Print the files to screen: grep -rI 'textstring' /Volumes/sharename/folder/  #capture the search in a file: grep -rI 'textstring' /Volumes/sharename/folder/ > ~/desktop/searchResults.txt 

* Dies kann sehr umfangreich werden, wenn Sie eine sehr lose Suche durchführen, da alle passenden Dateien erfasst werden.

Wenn Sie nur nach einer Datei suchen, können Sie so suchen

#display the results onscreen for a file ending in 'txt' find /Volumes/sharename/folder -name '*txt'  #capture the results in a file on your desktop. find /Volumes/sharename/folder -name '*txt' > ~/desktop/findResults.txt 

* Dies kann sehr groß werden, wenn Sie eine sehr lose Suche durchführen, da alle passenden Dateien erfasst werden.

Sie können eine Datenbank zum Speichern aller Dateien verwenden. Die Datenbank hat jedoch die Größe des Systems, in dem sie gespeichert werden, und Sie würden damit die Funktionalität des Dateisystems selbst replizieren.

Eine Alternative könnte darin bestehen, eine lokale Gruppe der mit rsync erstellten Dateien zu durchsuchen. Wenn sich auf dem Host-Computer kein rsync-Dämon befindet, können Sie weiterhin alle Dateien extrahieren, auf die Sie Zugriff haben. Wieder benötigen Sie so viel Speicherplatz wie die Dateien, die Sie extrahieren.

find ist NICHT schnell und genau der Befehl, den ich vermeiden möchte ... grep verarbeitet den Inhalt der Datei, nicht die Dateinamen. Es ist möglich, einen ls-Befehl an grep weiterzuleiten und auf diese Weise zu suchen. Die Dateinamen werden jedoch weiterhin mit der Geschwindigkeit der Netzwerkverbindung verarbeitet. Der einzige Punkt beim Versuch, eine Suchdatenbank zu erhalten, besteht darin, die exakte Lösung zu vermeiden, die Sie vorschlagen - fehlt mir etwas? tom stratton vor 11 Jahren 0