Ich habe einen Windows 10-PC und eine meiner Festplatten ist komplett kaputt gegangen (sie wird vom BIOS nicht erkannt, macht komische Geräusche und lässt sich nicht verwenden). Es war nicht die Systemfestplatte, sondern enthielt hauptsächlich private Daten. Ich weiß nicht mehr genau, was auf der Festplatte war, und das ist das Problem. Um den Verlust einzuschätzen (und um zu beurteilen, ob sich weitere Datenrettungsverfahren auf der Festplatte lohnen), würde ich gerne alle möglichen Hinweise darauf erhalten, was auf der Festplatte war (Dateinamen, möglicherweise mit Ordnernamen würden ausreichen).
Ich dachte, dass die Windows-Suche mit ihrer Dateiindizierung vielleicht über Informationen zu den irgendwo auf der Festplatte gespeicherten Daten verfügt und dass diese Informationen, wenn auch nur teilweise, irgendwie abgerufen werden könnten.
Ist es möglich, auf die Windows-Suchdatenbank zuzugreifen und eine Liste der Dateien mit Pfaden vom verlorenen Laufwerk abzurufen und wenn ja, wie?
Bitte beachten Sie, dass es bei dieser Frage nicht um die Datenwiederherstellung der defekten Festplatte geht, sondern darum, welche Informationen Windows über Dateien speichert, die sich auf Festplatten befanden (aber derzeit nicht dort sind). Der Windows-Dateisuchindex scheint ein möglicher Ort zu sein, an dem solche Informationen gespeichert werden könnten.
Antwort1
Mit Hilfe eines Kommentars vonDr. Moishe PippikEs ist mir gelungen, auf die Windows-Suchdatenbank zuzugreifen.
Der Suchinhalt wird standardmäßig gespeichert unter
C:\ProgramData\Microsoft\Search\Data\Applications\Windows\Windows.edb
Es handelt sich um eine ziemlich große Datei (in meinem Fall 1 GB) und kann normalerweise nicht woanders hin kopiert werden, da sie von der Windows-Suche verwendet wird. Öffnen Sie einfach den Task-Manager, suchen Sie nach „Microsoft Windows Search Indexer“ und beenden Sie den „Windows Search“-Prozess. Kopieren Sie dann die Datei Windows.edb an einen sicheren Ort.
Informationen zum Dateiformat der Suchdatenbank finden Sie beispielsweise in diesem Dokument vonHoward Chivers, der diewdsCarveSoftware, die anscheinend nicht zum Download verfügbar ist. Es gibt auchDasUndDieser Artikelvon Joachim Metz. Joachim Metz scheint auch der Hauptautor zu sein vonAbonnierenauf Github, das jedoch keine Binärversionen für Windows enthält und als experimentell gekennzeichnet ist.
Kurz gesagt scheint die Windows-Suchdatenbank auf dem Extensible Storage Engine (ESE) Database File (EDB)-Format zu basieren, einem proprietären, nicht dokumentierten Dateiformat von Windows mit zusätzlichen Verschleierungs- und Komprimierungselementen.
Schließlich fand ich ein Projekt vonJeonghyeon Kimab 2018 genanntWinSearchDBAnalyzer, mitQuellen(zusätzliche AbhängigkeitWinforms) auf Github. Laut dem Blog ist es kostenlos (zu verwenden), es sind Binärdateien für Windows verfügbar und außerdem könnte ich mit der Visual Studio Community Edition von Microsoft das Programm problemlos selbst erstellen.
Die Verwendung ist unkompliziert. Man kann einen Windows.edb-Dateispeicherort auswählen und dann einige Flags überprüfen, um zu ermitteln, wonach gesucht werden soll. Es dauerte dann eine Weile (~5 Minuten) und zeigte dann etwa 100.000 Einträge in einer Tabelle an. Das Sortieren nach Dateispeicherort ist einfach und für jede Datei werden Metadaten angezeigt.
Um jedoch auf meine ursprüngliche Absicht zurückzukommen: Die Anzahl der Dateien auf der verlorenen Festplatte, die noch in der Windows-Suchdatenbank vorhanden waren, war enttäuschend gering. Von den Hunderttausenden von Dateien auf dieser Festplatte waren nur maximal 1/10 oder weniger enthalten (eigentlich die Dinge, an die ich mich noch erinnere), sodass es am Ende viel weniger hilfreich war, als ich dachte. Dennoch ist es eine praktikable Möglichkeit, zumindest auf einige Metadaten über den Inhalt von Festplatten zuzugreifen, die nicht mehr vorhanden und zugänglich sind.
Antwort2
Diese Antwort bezieht sich auf Trilarions Antwort auf seine eigene Frage.
Das interessante Dokument, auf das Dr. Moishe Pippik verlinkt hat, beschreibt den Umfang der Indizierung. Das könnte den niedrigen Prozentsatz indexierter Dateien erklären.
Darüber hinaus können Sie testen, was passiert, wenn Sie dem Indexer eine Datei mit zufälligem Inhalt vorlegen. Erscheint diese Datei in der Datenbank oder nicht?
Ein unbekanntes Dateiformat kann vom Indexer nicht gelesen werden. Soweit ich weiß, konnte der Indexer in älteren Windows-Versionen durch die Bereitstellung von kompiliertem Code erweitert werden, der es dem Indexer ermöglichte, das von ihm erstellte Dateiformat zu lesen.
Es kann vorkommen, dass Dateien, die technisch nicht indexiert werden können, nicht im Index auftauchen.
Antwort3
Als Erstes muss man sehr präzise und detailorientiert sein. Sie sagten „im Sinne von überhaupt nicht zugänglich“. Ist das normale englische Grammatik? Als Nächstes ist „überhaupt nicht zugänglich“ nicht präzise. Viele würden sagen, dass ihr Laufwerk „überhaupt nicht zugänglich“ ist, wenn der Laufwerksbuchstabe noch da ist und der Inhalt als „Raw“ markiert ist.
Meine Definition wäre, dass das Laufwerk als „überhaupt nicht zugänglich“ betrachtet werden muss, wenn es beim Hochfahren keine Anomalien aufweist, aber alle Leseversuche des Computers fehlschlagen.
Dies ist ein völlig anderes Verständnis desselben Ausdrucks.
Die ersten Dinge, die Sie tun können, sind sehr einfach. Sie verwenden vorzugsweise eine Linux-Maschine, schließen das Laufwerk an und überprüfen seine Anwesenheit mit dem Befehl lsblk. Anschließend erstellen Sie mit smartmontools eine Protokolldatei und analysieren diese. Als Nächstes können Sie – wenn der Inhalt der Protokolldatei nichts dagegen aussagt – versuchen, das Laufwerk mit ddrescue und seiner Protokolldateifunktion zu duplizieren. Dadurch erhalten Sie ein hoffentlich weitgehend vollständiges Duplikat auf einem intakten Laufwerk und eine Liste der fehlenden Bereiche, die nicht kopiert wurden.
In Ihrer Paranoia würden Sie das Duplikat schnell duplizieren und an der zweiten Kopie arbeiten. Je nach Budget würden Sie verschiedene Wiederherstellungsprodukte für die zweite Kopie ausführen. Ein kostenloses und Open-Source-Programm für Fingerabdrücke wie Photorec würde Ergebnisse ohne Metadaten wie Verzeichnis- und Dateistrukturen liefern, aber die brauchbare Ausgabe von Photorec würde Ihren Speicher wieder auf den richtigen Weg bringen, was Sie darauf gespeichert haben.
Diese Analyse kann auch auf einem Windows-Rechner mit Ihrer zweiten Kopie problemlos durchgeführt werden. Wenn die gesammelten Informationen nicht ausreichen, können Sie mit Ihrer Arbeit beginnen.
Sie sollten sich zunächst mit den am häufigsten verwendeten Partitionsschemata wie dem alten Intel/MBR-Schema vertraut machen und auch GPT lernen. Die kostenlose Open-Source-Software Testdisk ist ein gutes Tool, das Sie dabei unterstützt.
Wenn Sie das verwendete Dateisystem kennen, das Sie beim Formatieren des Laufwerks verwendet haben, müssen Sie das entsprechende Dateisystemformat, z. B. NTFS, erlernen. Da NTFS am Anfang etwas schwierig ist, sollten Sie lieber mit FAT-Dateisystemen üben. Sobald Sie damit vertraut sind, können Sie es ausprobieren, indem Sie einen Teil oder die gesamte FAT (Dateizuordnungstabelle(n)) eines FAT-Dateisystems überschreiben. Dann ist ein wenig Programmierung erforderlich, um die Überreste davon zu durchsuchen. Sie sollten dann lernen, wie sich die Defragmentierung auf Ihren Erfolg auswirkt.
Nachdem Sie eine einfache Dateisystemimplementierung verstanden haben, gelangen Sie (vermutlich) zu NTFS. Ihr einziger Vorteil gegenüber einem Wiederherstellungsprogramm besteht darin, dass Sie den verbleibenden Speicher Ihres Laufwerksinhalts zu Ihrem Vorteil nutzen können.
Dies kann zwar zum Erfolg führen, eine Garantie gibt es jedoch nicht.
Im Jahr 2001 untersuchte ich ein ausgefallenes XP-Systemlaufwerk, das noch ein FAT-Dateisystem verwendete. Das einzige, was ich wiederherstellen konnte (was überhaupt von Bedeutung war), war die Einladungsliste (xls-Datei) seiner Hochzeit mit den bereits verschickten Einladungen. Es gab keine Möglichkeit, die Datei automatisch wiederherzustellen – ich musste mir die verschiedenen folgenden Cluster ansehen. Da es sich um eine xls-Datei handelte, war sie nicht komprimiert. Ich sah einfach den zweiten Cluster der Datei und es war nicht der folgende in linearer Reihenfolge. Heute wäre mir diese Aufgabe angesichts der in Excel-Dateien vom Typ xlsx verwendeten Komprimierung nie gelungen.