*.txt Datei Durchsuchen !?!

[Hagen Reddmann]

@Andreas, d.h. konkret, daß falls ich diesen Index-Dienst installiert habe wird ein Such Index über ALLE Dateien erstellt der jeden beliebigen Text, sei es ASCII, WideChars oder beliebige Bytesequenzen ALLER Dateien enthält. Ich halte dies für unmöglich, da ja dann der Index bzw. die Index-Dateien kombinatorisch gesehen viel viel größer als alle Dateien zusammen sein müsste.
Angenommen ich suche viele verschiedene Bytesequenzen in allen Dateien, dann müsste ja der Such-Index alle Dateien Byteweise zerpflücken und zu jeder Bytesequenz einen Index-Eintrag besitzen.
Eine 10 Bytes große Datei hätte dann mindestens 9 Index-Einträge für jede der 10 Bytes als Sequenz betrachtet.<br>

Es stellt sich mir nun die Frage wie dieser Indexdienst genau funktioniert und ob er tatsächlich jede beliebige Bytesequenz findet ??

Angenommen dieser Indexdienst beschränkt sich auf lesbare Texte, dann stellt sich sofort die Frage was als lesbarer Text interpretiert bzw. gefiltert wird, und somit die Frage nach der Suche "hat mein Index tatsächlich ALLE findbaren Patterns aus ALLEN Dateien gefunden ??".

Auf Grund der Datenmenge glaube ich nicht das der Indexdienst tatsächlich einen Index über alle Dateien und deren kompletten Inhalt erzeugt, sondern eher nur über ausgewählte Dateien. In diesem Falle wäre eine schnelle Textsuche, wie oben gezeigt, sehr wohl von Interesse und wahrscheinlich um Längen schneller und speichereffizienter als die Erzeugung und Verwaltung eines Indexes.

Gruß Hage

[Andreas Kosch]

Hallo Hagen,

der Index-Dienst greift auf spezielle Filter-DLLs (die intern COM-Objekte für das Interface IFilter sind) zurück. Jeder Software-Hersteller, der eine eigene Dateiendung im Betriebssystem registriert, kann ebenfalls eine eigene Filter-DLL bereitstellen und registrieren. Die Firma Adobe macht das zum Beispiel für ihre PDF-Dateien. Wenn der Index-Dienst seinen Volltextkatalog für einzelne Wörter zusammen mit der Position in der Datei aufbaut, "fragt" er die zuständige Filter-DLL nach den zu indizierenden Wörtern ab. Im Fall eine TXT-Datei werden nur einzelne Wörter indiziert, wobei die sogenannten <i>noise Words</i> (Wörter, die in fast jeder Datei vorkommen wie zum Beispiel der,die,das,und,oder...) ignoriert werden. Je nach Filter-DLL darf der Anwender die Liste der Noise-Words erweitern. Beim Microsoft SQL Server 2000 steht zum Beispiel für jede Sprache (Deutsch, Englisch, Französisch etc.) eine eigene Konfigurationsdatei zur Verfügung, in der man eigene Noise-Words eintragen kann. Im Fall einer PAS-Datei sollte die Filter-DLL (falls Borland jemals eine zur Verfügung stellt) zum Beispiel die Zeichenfolgen "begin", "end", "function", "uses" usw. als Noise-Words betrachten, den eine Suche nach dieser Zeichenkette würde eine fast 100 prozentige Trefferquote ergeben, so dass der Volltextkatalog aufgebläht wird, ohne einen wirklichen Vorteil zu haben.

Der Vorteil der Filter-DLLs liegt darin, dass auch Wörter gefunden werden, die in der Datei durch ein Trennzeichen unterbrochen werden (Beispiel: Zeilenumbruch oder Trennstrich) oder bei denen die Schreibweise unterschiedlich ist (Beispiel: ss oder ß). Während eine byteweise Suche in diesen Fällen keinen Treffer finden kann, teilt eine spezifische Filter-DLL das eigene Dateiformat viel effektiver auf.

Der durchschnittliche Anwender ("Lieschen Müller") wird fast ausschliesslich nur innerhalb von Dateien suchen, die über ein Anwendungsprogramm (Textverarbeitung etc.) angelegt werden. Hier spielt der Index-Dienst seine Vorteile vollständig aus, zumal in diesen Dokumenten über den Eigenschaftsdialog auch eigenständige Attribute zugewiesen werden können, um den Inhalt der Datei näher zu beschreiben. Die Filter-DLL wertet auch diese Dateieigenschaften mit aus. Die Sonderfälle (tatsächlicher Bytevergleich) kommen dort eher selten vor.

Bei der heute üblichen Rechenleistung kann der Indexdienst im Hintergrund die Suche über den Volltextkatalog extrem beschleunigen. Während die klassische Suche über den Bytevergleich erst dann startet, wenn der Anwender die Suchfunktion startet, arbeitet der Index-Dienst ständig im Hintergrund. Wenn der Anwender die Suche über den Index-Dienst startet, ist diese zu diesem Zeitpunkt ja längst fertig, so dass in Bruchteilen einer Sekunde nur das Ergebnis (Abfrage des Volltextkatalogs) angezeigt werden muss.

Man kann den Index-Dienst auch dafür nutzen, um die tatsächlich byteweise zu durchsuchenden Dateien vorzusortieren, wenn in der Datei eine "suchfähige" Zeichenkette vorkommt. Wie bei einer Datenbank wird hier der Index-Dienst verwendet, um die Ergebnismenge der Abfrage über einen "Index" so einzuschränken, dass die langsame Suche über den Bytevergleich nicht mehr alle Dateien durchsuchen muss.

Für uns als Entwickler ist der Index-Dienst ein Schlaraffenland. Mit minimalem Aufwand ist der Zugriff aus dem eigenen Programm heraus möglich. Wenn notwendig, können wir auch eigene Filter-DLLs schreiben/registrieren, um das Verhalten des Index-Dienstes an unsere Sonderfälle anzupassen.
&#10

[Gesine Kuhlmann]

Hi,

Na die Diskussion hatten wir doch schon ;-)

1)
Der Indexdienst führt zu nichts anderem als einer unscharfen Suche. Wird irgendetwas nicht gefunden, dann kann man als BS-Hersteller zwar wunderbar sagen: 'Da hat wohl ein anderer Hersteller gepennt...', hilft den Nutzern aber nicht für fünf Pfennig.

2)
Gerade der durchschnittliche Nutzer wird sich in Zukunft also noch mehr wundern warum manche Suchausdrücke gefunden werden und andere nicht.

3)
MS versucht mit Hilfe des Indexdienstes die Scharte zuzukleistern, die seit Äonen aus der mangelhaften Dateityp-Unterscheidung resultiert. Vorallem ist es auch mit ( oder gerade mit ) Indexdienst ein schöner Spaß, wenn sich mehrer Filter-DLL's für die gleiche Dateiendung verantwortlich fühlen. Der Aufsatz auf diese prinzipbedingte Schwäche des Dateisystems führt also zwangsläufig zu einem noch größeren Kuddelmuddel.

4)
Schönes Schlaraffenland, in dem dann noch nicht mal mehr gezielt Dateien gefunden werden können, da man ja nie weiss welche Filter im Hintergrund für welche Dateien zuständig sind und den Suchausdruck vielleicht als 'Noise' betrachten.

5)
Der Indexdienst ist ausserdem heute schon dafür verantwortlich, dass Rechner zeitweilig nicht mehr ansprechbar sind, da sie gerade damit beschäftigt sind, den 'unsichtbaren' Indexdienst zu bearbeiten. Das merken auch die durchschnittlichsten Benutzer und sind über diese Phänomen nicht gerade begeistert.

6)
Der Indexdienst ist Murks.

Gruß
Gesine

P.S.:
Dabei ist die Lösung doch so einfach. Siehe Macintos

[Hagen Reddmann]

Nungut, ich kann Andreas und auch Gesines Meinung verstehen. Es hängt halt vom Anwender ab. Ich persönlich betrachte mich als Power-User, d.h. nicht das ich viel mit meinem Rechner mache sondern eher das ich 4-5 Anwendungen gleichzeitig schnell bediene und exakte Resultate wünsche. Daher ist bei mir nichts vom Indexdienst übriggeblieben, er raubt mir unnötige Rechnenpower und gibt mir eben keine exakten Resultate zurück.<br>

Wenn diese IFilter benötigt werden, und diese erst in XP so richtig unterstützt werden, dann heist das doch auch das diese Suchfunktionen erst im XP zu gebrauchen sind ??

Gruß Hage

[Andreas Kosch]

Hallo Hagen,

&gt;dann heist das doch auch das diese Suchfunktionen erst im XP zu gebrauchen sind ??

nein - diese Option steht seit Windows NT 4 zur Verfügung. Die Neuerung von Windows XP besteht nur darin, aus der "Kür" eine "Pflicht" zu machen. In meinen Anwendungen habe ich das auch unter Windows 2000 ausgenutzt.

Zum Einwand von Gesine:

&gt;Der Indexdienst ist ausserdem heute schon dafür verantwortlich, dass Rechner zeitweilig nicht mehr ansprechbar sind

Ab einem Pentium III mit 500 MHz läuft die CPU im Leerlauf (d.h. die durchschnittliche Last liegt unter 50%). Der Index-Dienst hört bei einer Benutzeraktion sofort auf und beginnt seine Arbeit erst dann wieder, wenn der Benutzer ca. 60 Sekunden nichts macht. Über die <i>Computerverwaltung | Indexdienst</i> kann man dies jederzeit mitverfolgen, der Indexdienst zeigt dort seinen Status an.

Vielleicht überzeugt ein Beispiel aus der Praxis: Ein Messlabor bekommt die VDE-Normen in Form von PDF-Dateien, wobei regelmässige Änderungen vorkommen. Wenn ein Auftrag hereinkommt, sind 7890 PDF-Dateien mit insg. 1200 MByte Dateigrösse zu durchsuchen, um alle die Normen zu ermitteln, die für die zu messende Gerätekategorie relevant sind. Alle Dateien liegen auf einem zentralen Server. Es liegt auf der Hand, dass die 1,2 GByte PDF-Datei über das Netzwerk nicht in einer vertretbaren Zeitspanne auf klassischem Weg durchsucht werden können. Den Aufwand der ständigen Pflege einer eigenen Datenbank mit der Aufnahme aller möglichen Suchbegriffe will das Messlabor auch nicht gehen. Mit dem Indexdienst ist das Ergebnis in weniger als 1 Sekunde da (der Volltextkatalog für die Wörter aus den PDF-Dateien ist 30 MByte groß), wobei eine zusammengesetzte Suche nach mehreren Begriffen möglich ist. Ich glaube nicht, das das beste Tool auf einer LINUX-/Macintosh-Kiste diese Zeit toppen kann, zumal ich nur eine einzige SELECT-Abfrage für meine Suche über den Indexdienst schreiben musste :-)
&#10

[Robert Marquardt]

Herr Kosch,<br>
Sie argumentieren das es fuer den speziellen Fall geht (PDF) waehrend der allgemeine Fall prinzipbedingt (!) nicht zuverlaessig funktionieren kann

[Hagen Reddmann]

Angenommen, ALLE Hersteller würden für ALLE möglichen Dateiformate einen IFilter registrieren, der natürlich KEINERLEI Suchmusterunterdrückungen vornimmt. Dann wären wir bei dem Punkt das wirklich alle Pattern gefunden werden können, also so wie der obige Suchalgo. Aber ich kann jetzt schon voraussagen das dann der Indexdienst in die Kniee gehen muß. D.h. so wie der Indexdienst jetzt funktioniert kann er garnicht ALLE Informationen/Dateitypen berücksichtigen. Das ist natürlich auch ein vorteilhaftes Argument, da KEIN Mensch wirklich alle Dateiformate benötigt. In meinem Falle sind es meistens nur Quelltext Dateien wie *.PAS, *.H, *.C??
Die Nutzung eines Indexdienstes verbietet ja eben nicht auch noch GREP oder andere direkte Such-Tools nutzen zu können.<br>

Somit wären wir wieder am Anfang, und wissen nun das es einfach mal interessant ist eine Boyer-Moore PASCAL Implementierung zu sehen die schneller als System.Pos() einen Suchstring zu finden vermag.<br>
Es wäre für mich also trotzdem noch interessant zu wissen wie man diesen Boyer-Moore so umfrickelt das er multiple Suchmuster in einem Rutsch ausführt !?? Anregungen, Links oder Infos ??

Hage

[Gesine Kuhlmann]

Hi,

1)
Wir haben nicht nur einen Nutzer, der sich mit der Fehlermeldung 'Der Computer ruckelt' ( W2k ) bei uns beschwert. Bisher konnten wir diesen 'Ruckel'-Effekt immer zuverlässig abstellen, wenn der Indexdienst abgestellt wurde.

2)
Das Beispiel mit einem zentralen Server, der von kompetenter Hand administriert wird und einen Indexdienst bedient, ist durchaus eine praktikable Lösung. Allein auf Client-Systemen hat ein Indexdienst nichts zu suchen. Zumindestens solange, wie noch nicht einmal die Grundvoraussetzungen erfüllt sind ( siehe 4 ).

3)
Mac habe ich in diesem Zusammenhang angeführt, da dort schon das Filesystem dafür sorgt, dass wichtige Informationen automatisch mit abgelegt werden ( Resource-Fork ). Deshalb <b>funktioniert</b> in dieser Umgebung auch dokumentenzentriertes Arbeiten. So kann z.B. sogar die richtige Programmversion zu einem Dokument automatisch gestartet werden.

4)
Bei MS ändert ein Nutzer die Dateiendung und Word versucht tapfer eine TIF-Datei zu öffnen ( Mal ganz davon abgesehen, das es unter MS-Systemen an Übermut grenzt ein und das gleiche Programm in unterschiedlichen Versionen zu installieren ). Der mangelhaften Basisarchitektur dann noch die Krone aufzusetzen und Indizes darauf zu bilden, zeugt von mächtig viel Ignoranz.

5)
Würde MS endlich mal seine Hausaufgaben machen und nicht mit immer neuem, überflüssigem und größtenteils kontraproduktivem Firlefanz auf die Marketingtrommel ( und damit auch Nutzer ) hauen, dann wären die Systeme sicherlich auch eines Tages mal guten Gewissens einsetzbar.

Gruß
Gesin

[Max Reinhardt]

<pre>
Hallo,

welcher Sadist nötigt eine MS-Hasserin (Gesine K.) eigentlich
in Delphi (ist nun mal eine Win-Dev-Umgebung) zu programmieren?
Muss ein Sadist sein...

Ich würde mir bzgl. Dev-Umgebung eine saubere Trennung wünschen:

- MS übernimmt Delphi und macht daraus eine (Pascal-Dev-)Umgebung
die genauso leistungsfähig ist wie die anderen neuen DotNet-
Sprachen (Delphi wäre bei Anders Hejlsberg ohnehin in besseren Händen).

- Borland bleibt mit Kylix bei Linux (ohne Kompromisse wie sowieso
witzlose und illusionäre "Plattformunabhängigkeit") und versucht
die CLI-verliebten Linux-Coder mal endlich an Grafik-GUI-
Entwicklung zu gewöhnen (dann ist die vermeintliche Stabilität von Linux allerdings evtl. auch hin..).

Ein für-Delphi-langsam-die-Felle-wegschwimmend-sehender
MR

</pre&gt

[Hagen Reddmann]

Naja, ich sehe die Sache so: Dauernd werden wir Programmer vom Chef gezwungen schnell was hinzupfuschen, 3 Monate später maulen dann die Kunden, in der zwischenzeit hat ein MS-Ars... das komlette API geändert und ein Werbemensch hat neue Strategien wie wir zu coden haben entwickelt. All diesen Frust darf der Coder NICHT und NIEMALS zu Hause rauslassen, die Zeit reicht aber nicht für weitere Hobbys wie Rugby, Mülltonnen eintreten usw. <i>da ist doch solch ein Forum genau richtig </i> Hier wird man noch verstanden was viel wichtiger ist als immer der gleichen Meinung zu sein

Gruß Hagen

PS: im übrigen ich genieße Gesines Beiträge seh

[Gesine Kuhlmann]

Hi,

1)
Das einzige was ich hasse sind unverschlossene Zahnpastatuben.

2)
Wenn man sich nicht nur um eine BS-Umgebung kümmern muss, dann fallen die Vorteile und Nachteile einzelner BS deutlich auf. Das es bei objektiver Betrachtung über MS leider viel zu viel zu meckern gibt, ist nunmal nicht meine Schuld. Das es in anderen Umgebungen auch zu meckern gibt ist klar. Da wir uns hier aber in einem Delphi-Forum befinden, interressieren Meckereien darüber in diesem Forum wohl nur die wenigsten.

3)
Natürlich kann man auch seine Augen verschliessen und getreu dem Motto "Die Partei hat immer recht..." Missstände einfach ignorieren bzw. sich darüber freuen, dass beim Kopieren kleine Blättchen von links nach rechts fliegen, es aber bis heute nicht möglich ist, bei einem Fehler während des Kopierens ( z.B. der Dateiname ist zu lang oder ungültig.... ) diese zu sammeln und in einer Liste auszugeben um diese nach Abschluss dann gesondert zu behandeln. Nö, man stößt bei Datei 53.498 auf einen Fehler und weiss noch nichtmal was kopiert wurde, sondern fängt wieder von vorn an. Na dafür ist XP aber schön bunt.

4)
Danke Hagen ;-)

Gruß
Gesin

[Hagen Reddmann]

@Gesine, <i>"Die Partei hat immer recht..." </i> stammst Du aus der "rechten" Hälte Deutschlands ?

Hage

[Gesine Kuhlmann]

Hi Hagen,

Nein, aus Hamburg.

Gruß
Gesin

[Robert Marquardt]

Zahnpasta? Was ist Zahnpasta

[Gesine Kuhlmann]

Hi,

Na das weisse Zeug ( manchmal mit bunten Streifen ), das man auf kleine Bürstchen aufträgt um sich anschliessend damit im Mund rumzurühren ;-)

Gruß
Gesin