Windows eigene Suchfunktion über Python benutzen?

[microkernel]

Moin!

Mich würde mal interessieren, ob es eine Möglichkeit gibt, die Windows interne Suchfunktion über Python anzusteuern. Ich habe auf Wikipedia gelesen, dass die Windows Suche eine Indexdatenbank mit einer .ebd Endung anlegt, in der alle indizierten Dateien mit zusätzlichen Infos gespeichert werden. Diese Datenbank würde Suchfunktionen in Programmen deutlich beschleunigen... Allerdings konnte ich diese Datenbank noch nicht einmal finden. Und selbst wenn ich sie finden würde, frage ich mich, ob das Datenbankformat über Python ansprechbar ist
http://de.wikipedia.org/wiki/Windows_Search

Lg
microkernel

[EyDu]

Als kleiner Hinweis: nutze die englischsprachige Wikipedia

[BlackJack]

@microkernel: Der Dienst hat auch eine API und man kann ein SDK bei Microsoft herunterladen. Da würde ich als erstes mal schauen ob und wie man an die Daten heran kommt.

[microkernel]

Danke! Hab die Lösung jetzt gefunden. Ist sogar ne reine Python Lösung (ohne direkte Anbindung irgendwelcher DLLs). Mit der adodbapi kann man auf die Datenbank wie folgt zugreifen:

Code: Alles auswählen

import adodbapi
connection = adodbapi.connect("Provider=Search.CollatorDSO;Extended Properties=\"Application=Windows\"")

...und schon hat man Zugriff auf die Indexdatenbank. Mittels

Code: Alles auswählen

cursor.execute("""SELECT "System.ItemPathDisplay", "System.ItemDate" FROM "SystemIndex" WHERE WorkId IS NOT NULL AND scope='file:' AND Contains(System.ItemType,'"docx"')  ORDER BY System.ItemDate DESC""")

kann man nun beispielsweise nach allen *.doxc Dateien suchen (sortiert nach letzter Änderung).

Mein Problem ist jetzt allerdings, dass ich die Pfade übersetzt bekomme. Also aus bspw.

Code: Alles auswählen

u'C:\\Users\\Ich\\Documents\\th1.docx'

wird

Code: Alles auswählen

u'C:\\Benutzer\\Ich\\Eigene Dokumente\\th1.docx'

, was wiederum einen IOError zufolge hat, wenn ich die Dateien direkt öffnen will. Kennt jemand eine verlässliche Methode, diese Pfade zu "übersetzen"?

[microkernel]

Habs jetzt wie folgt gelöst:

Code: Alles auswählen

def translate_path(path):
	fragments = path.split(os.sep)
	translations = [
		(1, "Benutzer", "Users"),
		(1, "Programme", "Program Files"),
		(3, "Eigene Dokumente", "Documents"),
		(3, "Eigene Bilder", "Pictures"),
		(3, "Eigene Videos", "Videos"),
		(3, "Eigene Musik", "Music"),
	]
	for pos, gerName, engName in translations:
		if fragments[pos] == gerName:
			fragments[pos] = engName

	return os.path.join("C:", os.sep, *fragments[1:])

[snafu]

Hm, das mit den Positionsangaben finde ich im ersten Moment etwas komisch, aber man kann damit leben. Ich würde den Pfad aber wohl vorher durch `os.path.realpath()` jagen, damit die Funktion auch mit relativen Pfadangaben und sowas klarkommt.

[EyDu]

Zum Aufteilen von Pfaden gibt es die wunderschöne os.path.split-Funktion, da solltest du nicht selber etwas mit str.split und os.sep basteln. Auch sollte bei dem os.path.join kein os.sep in den Argumenten auftauchen.

Viel problematischer finde ich aber, dass deine Funktion sehr viele Einschränkungen hat. So werden nur deutsche Systeme unterstützt und auch nur Übersetzungen, welche du explizit angegeben hast. Und das ganze steht dann auch noch auf so wackeligen beinen mit Positionsangaben im Pfad, was nur durch Glück keine Fehler produziert.

Wenn ich einen Tipp abgeben müsste, wo der Fehler liegt, dann würde ich auf das Öffnen setzen. Mein Tipp: du gehst falsch mit den Leerzeichen in Pfaden um. Was passiert denn, wenn du Ergebnisse aus "Program Files" öffnen möchtest?