Ordnerstruktur von ext. Festplatte zerschossen (Hieroglyphen) - MFT defekt? Chkdsk sinnvoll?

3854387

Cadet 2nd Year
Registriert
Apr. 2019
Beiträge
21
Hi zusammen,

ich habe ein Problem mit einer meiner externen Festplatten. Richtig schlau werde ich daraus nicht.

Es ist mir mit dieser Festplatte jetzt schon mehrfach passiert, dass statt der normalen Ordnerstruktur nur noch Hieroglyphen angezeigt werden. Im laufenden Betrieb trat das Problem auf einmal ein. In den letzten Wochen funktionierte die externe Festplatte wunderbar und fehlerfrei. Jetzt trat das Problem wieder auf und es hat sich bis jetzt noch nicht wieder von selbst behoben. Bevor ich schwerere Geschütze auffahre, wollte ich hier mal nachfragen, um was für ein Problem es sich handeln könnte und wie man es zielgerichtet beheben könnte.


Kurzversion, damit nicht jeder alles lesen muss ;) (alles aus der Kurzversion steht auch in längerer Erklärung in der unteren Exkurs-Version):
-------------------------------------------------------------------------
Zwei Dateien:
1. IndexerVolumeGuid
2. WPSettings.dat

Weiß jemand, um was für Dateien es sich dabei handelt? In welchen Fällen werden sie erstellt? Inwiefern haben sie zur Behebung der Probleme vor einem Monat geführt, oder haben sie damit überhaupt nichts zu tun?


Bevor ich jetzt Chkdsk oder anderes laufen lasse, dachte ich mir, ich frage hier lieber mal nach. Viele Threads hier und in anderen Foren hatte ich (speziell im letzten Jahr) schon überflogen. Einiges habe ich dabei gelernt. Aber wirklich verstanden habe ich wie gesagt immer noch nicht, was eigentlich das Problem ist und warum kein Datenverlust eintritt, obwohl man eigentlich vermuten würde, dass die Festplatte hinüber ist. Was in den Threads zur Hieroglyphen-Problematik und zu anderen Stichworten, nach denen ich gesucht hatte, auch vielfach gesagt wurde. Ist das Problem, dass der Master File Table (MFT) beschädigt ist? Warum wurde mir zig mal (nach Neustart oder anderen harmlosen Versuchen ohne drastische Maßnahmen) nach mehr oder weniger kurzer Zeit wieder alles normal angezeigt? Wovon ist es abhängig, wie schnell/ob mir wieder alles angezeigt wird?

Danke an euch schon mal fürs Lesen. Ich hoffe, dass der ein oder andere eine Idee hat oder selbst ein ähnliches Problem hat/hatte. Vielleicht hilft das hier ja auch dem ein oder anderen mit defekter Festplatte, der in Zukunft auf diesen Thread stößt.
-------------------------------------------------------------------------
Kurzversion-Ende


Exkurs zur Erläuterung:
-------------------------------------------------------------------------
Rein physikalisch ist jetzt nichts daran passiert - eventuell in der Vergangenheit schon, was die Schäden verursacht haben könnte. Dann würde mich aber wundern, dass ich die Platte monatelang ohne Probleme nutzen und komplett (3,63 TB) füllen kann, ohne dass Datenverlust auftritt. Bis wieder dieser Fehler kommt. Ebenfalls möglich ist, dass die Festplatte in der Vergangenheit Schaden genommen hat, aufgrund von Abstürzen (Stromausfall) bzw. Abziehen des USB-Steckers im laufenden Betrieb (ohne Hardware entfernen). Das ist meine Vermutung, da es wohl eine gängige Ursache solcher Hieroglyphen-Probleme ist. Erst seit den Problemen achte ich auf einen sicheren Umgang mit den Festplatten (inklusive "Hardware sicher entfernen"), während sie in Betrieb sind. Nun könnte ich einfach eine neue Festplatte kaufen und fertig. Aber ich möchte der Problematik doch auf die Spur kommen, weil die Festplatte auch nach Auftreten dieser Fehler wieder einwandfrei funktionierte/funktioniert.

Zum ersten Mal hatte ich das Problem vor etwa 2 Jahren schon. Während Downloads auf die Festplatte konnte auf einmal nicht mehr auf die Ordner zugegriffen werden, da die Ordnernamen sich in Hieroglyphen umgewandelt hatten. Bis zur Ordnerebene, auf der die Probleme auftraten, waren die Ordnernamen ganz normal und die Ordner ließen sich öffnen. Ab der Ordnerebene mit Hieroglyphen ließen sich Hieroglyphen-Ordner und -Dateien nicht mehr öffnen oder bearbeiten. Nach dem ersten Schock startete ich den Laptop neu oder schaltete die Festplatte aus. Schon funktionierte wieder alles und wurde normal angezeigt (oder vielleicht etwas später, aber jedenfalls ohne größeren Aufwand). Das passierte mehrfach in solch kurzzeitiger Form. Erst vor etwa einem Jahr trat das Problem auf, ohne dass es sich von selbst wieder rasch behob. Da ich zu diesem Zeitpunkt auch nur wenige der Daten als Backup auf anderen Festplatten gesichert hatte, begab ich mich auf die Suche nach Ansätzen zur Lösung des Problems. Einerseits durch Programme, die Reparaturen an verschiedenen Stellen defekter Festplatten vornehmen können. Andererseits durch Ansätze zur Rettung möglichst vieler Daten. Neben dem Windows-eigenen chkdsk /f /r habe ich es noch mit verschiedenen detailreicheren Tools versucht, u.a. mit TestDisk. Letztendlich funktionierte die Festplatte wieder, aber die Daten wurden in FOUND.000, FOUND.001, usw. Ordner gesteckt und nach dem FILE0001.CHK-FILE9999.CHK Prinzip benannt.

Einiges konnte ich rekonstruieren, problemlos, wenn es sich um einzelne größere Dateien handelte. Diese waren in intaktem Zustand, mit der passenden Dateigröße, konnten sofort entsprechend umbenannt werden und konnten ohne Fehler geöffnet werden. Nichts fehlte. Datenverlust im eigentlichen Sinne ist nicht entstanden. Aber Tausende kleine Dateien zu überprüfen, verschiedene Dateitypen auszuprobieren, usw. wäre/ist sehr mühselig gewesen. Bilder konnte ich rekonstruieren, indem ich testweise alle Dateien eines Ordners in die entsprechenden .jpg (u.a.) Dateitypen umwandeln ließ. In einigen Fällen beinhaltete auch die Ordnerstruktur Informationen, bzw. alles wieder zu ordnen, war sehr mühselig. .txt-Dateien und andere Textdateien konnte ich bislang überhaupt nicht rekonstruieren. All dies war kein Weltuntergang, aber ich würde es natürlich gerne vermeiden. Natürlich habe ich vieles und vor allem alle wichtigen Daten auf anderen Festplatten in mehrfacher Ausfertigung gesichert. Allerdings habe ich diese Festplatte gerade dafür genutzt, neue Dateien zwischenzuspeichern, bevor ich sie sozusagen (auf sicheren Festplatten in mehrfacher Ausfertigung) geordnet archiviere. Entsprechend sind jetzt doch wieder große Mengen an Dateien und Ordner noch nicht als Backup vorhanden. Auch Arbeit für Ordnerstrukturen und Informationen in einigen .txt-Dateien.

Nachdem ich die Festplatte also vor rund einem Jahr einmal mit allen möglichen Mitteln bearbeitete, funktionierte sie also wieder. Was letztendlich die Lösung war (und ob es überhaupt ein gravierendes Problem gab, das die Mittel benötigt hat), konnte ich nicht herausfinden.. Es funktionierte wieder alles, aber die alte Ordnerstruktur war eben durch die FOUND.000, FOUND.001, usw. Ordner ersetzt worden (das müsste das Windows-eigene Chkdsk über die /r Funktion gemacht haben, oder?). Danach trat das Hieroglyphen-Problem noch ein paar Mal in unterschiedlichen Abständen auf. Mal dauerte es länger, bis wieder alles funktionierte. Mal reichte ein direkter Neustart des Laptops. Ich bin jedenfalls ohne härtere Mittel ausgekommen und habe darauf jedes Mal bewusst verzichtet, um nicht wieder die funktionsfähige Ordnerstruktur durch unsortierte Recovery-Haufen zu ersetzen. Jetzt hatte ich zu Beginn des Jahres einen neuen Laptop gekauft (jetzt Windows 10, vorher noch ein alter Laptop mit Windows 7). Seitdem hatte ich einmal das Hieroglyphen-Problem, vor gut einem Monat. Während eines Downloads war die Ordnerstruktur auf einmal auf die typische Weise zerschossen. Hieroglyphen-Ordner und -Dateien, die sich nicht öffnen ließen. Nach dem Neustart des Laptops muss irgendetwas mit der Festplatte passiert sein. Die übliche Meldung zur Überprüfung und Reparatur der Festplatte ("Laufwerk wird überprüft und repariert") hatte ich abgebrochen. Trotzdem vermute ich, dass der Laptop irgendeine Art von Reparatur an der Festplatte vorgenommen hat. Zum einen funktionierte die Festplatte tatsächlich sofort nach Neustart einwandfrei. Zum anderen befanden und befinden sich 2 neue, mir unbekannte Dateien auf der obersten Ordnerebene der Festplatte.

Die Dateien heißen:
1. IndexerVolumeGuid
2. WPSettings.dat

Beide vor rund einem Monat erstellt, als ich den Laptop mit angeschlossener externer Festplatte neugestartet hatte.

Weiß jemand, um was für Dateien es sich dabei handelt? In welchen Fällen werden sie erstellt? Inwiefern haben sie zur Behebung der Probleme vor einem Monat geführt, oder haben sie damit überhaupt nichts zu tun?

In diesem Fall ist die Situation übrigens minimal anders (eventuell auch andere Male schon):

  • Zunächst trat die Hieroglyphen-Situation auf und ich konnte einige Unterordner mit Hieroglyphen-Dateien und -Ordnern als Inhalt öffnen, ab denen ich dann nicht mehr öffnen konnte
  • Jetzt wird die oberste Ebene ganz normal mit Ordnernamen und Dateinamen (die beiden genannten Dateien) angezeigt. Einige der Ordner lassen sich nicht öffnen. Es kommt eine "Der Pfad ist nicht verfügbar"("Auf kann nicht zugegriffen werden. Die Datei oder das Verzeichnis ist beschädigt oder nicht lesbar")-Meldung. Einer der Ordner lässt sich öffnen. Die nächste Ordnerebene wird noch normal angezeigt. Inklusive .txt-Dateien, die sich normal öffnen und bearbeiten lassen. Der Ordner zur nächsten Unterebene lässt sich jedoch nicht mehr öffnen. Hieroglyphen, die erst auf den späteren Ordnerebenen folgten, bekomme ich jetzt nicht mehr zu sehen.
  • Ansonsten wird die Festplatte normal vom Laptop erkannt und angezeigt ("709 GB frei von 3,63 TB").
  • Mit ChrystalDiskInfo hatte ich die Festplatte übrigens irgendwann im Laufe des letzten Jahres nach den häufigen Hieroglyphen-Situationen getestet, weil ich natürlich schon wissen wollte, ob ich sie nicht lieber entsorge. Laut ChrystalDiskInfo in einem guten Gesamtzustand. Die Werte waren vergleichbar mit den Werten meiner anderen Festplatten und enthielten keine negativen Auffälligkeiten. Daraus habe ich geschlossen, dass es sich nicht um ein grundsätzliches physikalisches Problem der Festplatte handelt.
  • Vom Laptop ist die ganze Problematik übrigens nicht abhängig. Ein anderer Laptop hat es vorhin in genau der gleichen Weise angezeigt. Wie gesagt hatte ich nur den Eindruck, dass dieser Laptop bzw. dass Windows 10 daran irgendwie gezaubert und die "IndexerVolumeGuid"/"WPSettings.dat"-Dateien erstellt hat. Was mir vorher bei denselben Problemen (und plötzlichen Lösungen aus dem Nichts) im letzten Jahr mit dem alten Windows 7 Laptop nicht passiert ist.
  • Vorhin wollte der Laptop nach dem x-ten meiner Neustart-Versuche (ohne Selbstheilung) die Festplatte wieder überprüfen. Ich dachte mir spontan, ich lasse es einfach mal darauf ankommen und hoffe, dass nur irgendwelche Fehler repariert werden (/f), ohne dass Daten in der FOUND.000-Form wiederhergestellt werden (/r) oder sonst irgendetwas beschädigt wird. Allerdings hing die Anzeige gleich bei 0%, sodass ich es (auf die harte Tour) abgebrochen habe, bevor Schlimmeres an der Festplatte passiert.

Bevor ich jetzt noch einmal bewusst Chkdsk oder anderes laufen lasse, dachte ich mir, ich frage hier lieber mal nach. Viele Threads hier und in anderen Foren hatte ich (speziell im letzten Jahr) schon überflogen. Einiges habe ich dabei gelernt. Aber wirklich verstanden habe ich wie gesagt immer noch nicht, was eigentlich das Problem ist und warum kein Datenverlust eintritt, obwohl man eigentlich vermuten würde, dass die Festplatte hinüber ist. Was in den Threads zur Hieroglyphen-Problematik und zu anderen Stichworten, nach denen ich gesucht hatte, auch vielfach gesagt wurde. Ist das Problem, dass der Master File Table (MFT) beschädigt ist? Warum wurde mir zig mal (nach Neustart oder anderen harmlosen Versuchen ohne drastische Maßnahmen) nach mehr oder weniger kurzer Zeit wieder alles normal angezeigt? Wovon ist es abhängig, wie schnell/ob mir wieder alles angezeigt wird?

Ist eine Intenso-Festplatte, FAT32 Dateisystem.

Danke an euch schon mal fürs Lesen. Ich hoffe, dass der ein oder andere eine Idee hat oder selbst ein ähnliches Problem hat/hatte. Vielleicht hilft das hier ja auch dem ein oder anderen mit defekter Festplatte, der in Zukunft auf diesen Thread stößt.
-------------------------------------------------------------------------
Exkurs-Ende


Off-Topic Ein harmloseres, banaleres Problem: Weil der Laptop vorhin bei der Überprüfung der Festplatte feststeckte, ist mir Folgendes aufgefallen: Wie erzwinge ich denn das Ausschalten/Neustarten eines Laptops mit fest verbautem Akku, wenn er auf keine Eingaben reagiert?

Ein/Aus-Schalter gedrückt halten funktionierte wie erwartet nicht. Die bisherige Lösung über das Trennen der Stromversorgung fällt aufgrund des fest verbauten Akkus aus. Per Google konnte ich keine Lösung finden (aber auch keine Aussage dazu, dass es keine Lösung und andere ratlose Betroffene gibt). In diesem Fall war der Akku sowieso fast leer. Aber ansonsten kann es doch nicht sinnvoll sein, den Laptop über zig Stunden in solch einem hängenden Zustand zu lassen, bis sich der Akku endlich entlehrt hat. Ist das ein gängiges Problem, für das es keine Lösung gibt?


Edit: Screenshot vom aktuellen Zustand der Festplatte laut CrystalDiskInfo hinzugefügt.
 

Anhänge

  • CrystalDiskInfo 24.04.19.jpg
    CrystalDiskInfo 24.04.19.jpg
    318,2 KB · Aufrufe: 747
Zuletzt bearbeitet:
1) Platte: aktuellen Zustand mit crystaldiskinfo prüfen und Ergebnis hier posten,
2) Ein/Aus-Schalter 15sek drücken?
 
  • Gefällt mir
Reaktionen: 3854387
Egal wer Dir das erzählt hat..chkdsk rettet deine Daten NICHT.
 
Erstmal Willkommen im Forum.
Es ist viel Text und alles habe ich nicht gelesen, aber poste doch bitte mal den Screenshot von CrystalDiskInfo für die Platte. Ziehe unbedingt das Fenster soweit auf, dass alle Attribute und auch die Rohwerte vollständig sichtbar sind, also keine Scrollbalken mehr erscheinen. Bitte mache den Screenshot aus Windows und nicht mit einer Kamera vom Bildschirm und nur den Screen von CrystalDiskInfo, mit Alt+Druck erzeugt Windows einen Screenshot des aktiven Fensters in der Zwischenablage oder probiere mal die Tastenkombination: 'Windows Taste + Shift + S'.
 
  • Gefällt mir
Reaktionen: 3854387
@blöderidiot
1) Ist jetzt als Anlage eingefügt.
2) 15 Sekunden hatte ich sicher nicht gedrückt. Wahrscheinlich eher 5-10 Sekunden. Werde ich beim nächsten Mal versuchen ;)

Danke schon mal!

@emeraldmine
Auf die Probleme dieser Windows-Funktion bin ich dann auch im Laufe der Recherche gestoßen. Aber die FOUND.000, FOUND.001, usw. Ordner wurden doch mit der /r Recover-Funktion von Chkdsk erstellt, oder?

@Holt
Ja, pardon, dass es so viel wurde. Kein Problem, wenn nur Ausschnitte gelesen werden. Ich dachte, ich schreibe es in dieser Form, damit man die einzelnen Schritte nachvollziehen kann. Denn grundsätzliche Threads zu ähnlichen Problemen hatte ich ja schon gefunden.

Vielleicht kann man aus dem Screenshot ja etwas ableiten. Es wird jedenfalls nach wie vor angezeigt, dass der Gesamtzustand "gut" sei.
 
Ich muss @emeraldmine teilweise widersprechen. Natürlich ist chkdsk kein Programm für ein Datenrecovery, allerdings kann es durchaus Daten wiederherstellen.

Wichtig ist allerdings, dass du es mit folgenden Optionen startest: "chkdsk /f /r /b"
Dieses führt einen Scan der Datencluster des NTFS-Dateisystems durch und kann daher mittels der entsprechenden Prüfsummen Daten wiederherstellen, die andere Programme nicht retten können und auf der anderen Seite eine anschließende Reperatur fördern.

Es gibt jedoch wie bei allem anderen hier noch ein "aber": Sofern du die Daten forensisch wiederherstellen willst, würde das nach eine Prüfung durch chkdsk anschließend nicht mehr funktionieren.
 
  • Gefällt mir
Reaktionen: 3854387
3854387 schrieb:
FAT32 Dateisystem.

Geht in der Masse des Textes leicht unter. Ist allerdings hier relevant!

Bei einem Stromausfall oder ohne vorheriges Abmelden kann es relativ leicht die FAT zerschießen. Und dann kommt es zu diesen Hieroglyphen.

Soweit ich das im Kopf habe, gibt es 2 Kopien der FAT. Geht eine kaputt, kommt es erstmal zu diesem Verhalten. In welchen Fällen der dann auf die Backupfat zugreift und damit alles wieder gut aussieht, weiß ich allerdings jetzt auch nicht. Finde auch gerade die Dokumentation dazu nicht.

NTFS ist da robuster, aber auch nicht gefeit gegen Defekte.

Konvertiere die Platte nach NTFS, vorher aber bitte aktuelles Backup erstellen. ;)
 
  • Gefällt mir
Reaktionen: 3854387 und blöderidiot
3854387 schrieb:
Vielleicht kann man aus dem Screenshot ja etwas ableiten.
Ja, nämlich das die Platte offenbar im Dauerbetrieb läuft, dafür aber ist sie nicht gemacht. Die wird also vermutlich nicht die üblichen 5 Jahre der vom Hersteller geplanten Nutzungsdauer erleben, wenn sie weiter so genutzt wurde, denn solche einfachen Desktopplatten wie sie eben üblicherweise in den USB Gehäusen stecken, sind nur für 2400 Power-On-Hours pro Jahr ausgelegt. Ersetze sie dann also durch eine NAS Platte die Du selbst in ein USB Gehäuse einbaust, die NAS Platten vertragen den Dauerbetrieb.

Das ist aber hier weniger das Problem, sondern eher die 0x9E = 158 Ausschaltungsabbrüche, also unerwarteten Spannungsabfälle und bei USB Platten kommen diese vom Abziehen ohne sie Abzumelden und ggf. Wackelkontakten des Netzteilsteckers. Auch wenn die Richtlinien zum Cache der Platte entsprechend so eingestellt sind das der Cache deaktiviert ist, besteht dabei immer das Risiko das das Filesystem korrupt wird, mit den Folgen die Du gerade erlebt hast. Ist der Schreibcache aktiviert und womöglich das von Windows veranlasste Leeren deaktiviert, sind also beide Haken gesetzt, ist das Risiko deutlich erhöht.

Außerdem kann Datenkorruption vom RAM Fehlern kommen, Du solltest also auch mal das RAM Deines Rechners mit Memtest86 gründlich testen.
Rome1981 schrieb:
allerdings kann es durchaus Daten wiederherstellen.
Ja, aber chkdsk zieht vor allem das Filesystem gerade und wirft über Bord was im Wege zu sein scheint. Wenn man Daten retten will, sollte man gefälligst vorher kein chkdsk laufen lassen.
Rome1981 schrieb:
Wichtig ist allerdings, dass du es mit folgenden Optionen startest: "chkdsk /f /r /b"
Unsinn, bei /r werden nur alle Cluster geprüft ob sie lese- und beschreibbar sind und mit /b auch solche die vom Filesystem schon als defekt ausgeblendet wurden. Die eigentliche Funktion das Filesystem gerade zu ziehen, ist /f und /r enthält auch /f und /b die beiden anderen ebenfalls, also /b alleine hat den gleichen Effekt wie /f /r /b.
Ergänzung ()

Smurfy1982 schrieb:
Konvertiere die Platte nach NTFS
Vorsicht beim Konvertiere, da kommen oft lustige Clustergröße bei raus. Ich würde die Dateien extern speichern, man muss sowieso zu jeden Zeit ein Backup alles Dateien haben, die man nicht verlieren möchte und dann die Platte mit NTFS und 4k pro Zuodrnungseinheit (Cluster) neu formatieren (Schnellformat reicht).
 
  • Gefällt mir
Reaktionen: areiland und 3854387
Die Dateien die dir angezeigt werden kommen vom Windows Index Dienst.

Dort sind die Identifikation des Laufwerks gespeichert.

zur WPSettings.dat gibts es von MS keinerlei Infos. Ich vermute das WP steht für WriteProtection. Kann man mit diskpart checken ob da irgendwas geflagt ist.

Ja und wie schon erwähnt Fat32 weg Dafür NTFS oder exFat für Datenträger bis 120Gb, wenn überhaupt.

Fat32 nutze ich seit Jahren nicht mehr und kann mich an viele Probleme aus den 2000ern erinnern.
Oft zerschossene Zuordnungstabellen (MFT)..etc

Ich hab hier nur noch ne SATA zu USB Docking Station und da steck ich meine zig 2TB Platten im Betrieb rein und raus und hab seit 10 Jahren keine Probleme damit.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: 3854387
@Smurfy1982
Danke! Werde ich mir merken bzw. in Zukunft immer machen.

In der Tat hat die Platte noch das Dateisystem wie beim Kauf. Mittlerweile konvertiere ich immer erst entsprechend. Allerdings wegen der 4GB-Dateigrößenbegrenzung. Davon abgesehen hatte ich mich mit den Dateisystemen noch nicht beschäftigt.

FAT zerschossen...ja, das hatte ich im Zusammenhang mit den Hieroglyphen gelesen. Kann ich halt technisch nicht wirklich zuordnen bzw. ich weiß nicht, wie ich das überprüfen oder beheben könnte. Bzw. wie ich die Platte dazu bringe, auf die Backup-FAT zuzugreifen, wie Du sagst.


Smurfy1982 schrieb:
Soweit ich das im Kopf habe, gibt es 2 Kopien der FAT. Geht eine kaputt, kommt es erstmal zu diesem Verhalten. In welchen Fällen der dann auf die Backupfat zugreift und damit alles wieder gut aussieht, weiß ich allerdings jetzt auch nicht. Finde auch gerade die Dokumentation dazu nicht.



Holt schrieb:
Das ist aber hier weniger das Problem, sondern eher die 0x9E = 158 Ausschaltungsabbrüche, also unerwarteten Spannungsabfälle und bei USB Platten kommen diese vom Abziehen ohne sie Abzumelden und ggf. Wackelkontakten des Netzteilsteckers. Auch wenn die Richtlinien zum Cache der Platte entsprechend so eingestellt sind das der Cache deaktiviert ist, besteht dabei immer das Risiko das das Filesystem korrupt wird, mit den Folgen die Du gerade erlebt hast. Ist der Schreibcache aktiviert und womöglich das von Windows veranlasste Leeren deaktiviert, sind also beide Haken gesetzt, ist das Risiko deutlich erhöht.

Danke! Ja, als die entsprechenden Probleme im letzten Jahr auftraten, war ich mir bewusst, dass es wohl daher kommt. Seitdem halte ich mich daran, aber diese Platte hatte es offensichtlich erwischt.


Holt schrieb:
Vorsicht beim Konvertiere, da kommen oft lustige Clustergröße bei raus. Ich würde die Dateien extern speichern, man muss sowieso zu jeden Zeit ein Backup alles Dateien haben, die man nicht verlieren möchte und dann die Platte mit NTFS und 4k pro Zuodrnungseinheit (Cluster) neu formatieren (Schnellformat reicht).

Sobald ich die Ordnerstruktur/Daten wieder habe, konvertiere ich entsprechend. Jetzt habe ich aber ja keinen Zugriff. Vielleicht weil die FAT zerschossen ist und momentan nicht auf die Backup-FAT zurückgegriffen wird, wie Smurfy1982 vermutet. Könnte passen, soweit ich das beurteilen kann.

Hat die Master File Table damit etwas zu tun? Oder gibt es die wiederum nur beim NTFS-Dateisystem? Ich bin wie gesagt bei der Recherche auf diese Begriffe gestoßen, ohne näher die technischen Details zu kennen.


Wisst ihr, was es mit den beiden Dateien "IndexerVolumeGuid" und "WPSettings.dat" auf sich hat, die auf einmal auf der Festplatte aufgetaucht sind?
 
Also zum CHKDSK hab ich auch was zu berichten!!!

Habe von einem auf den anderen Tag meine 4TB Externe Platte zerschossen die voller Daten war. Pc aus am nächsten Tag an.
Dann war meine Externe Platte noch sichtbar aber im zustand Raw also ohne dateisystem. Konnte auf nix mehr zugreifen da immer die Meldung kam Dateisystem beschädigt, die Plattengröße konnte man auch nicht mehr sehen.

Dann hab ich einen bootfähigen Stick mit Linux erstellt und siehe da, Linux konnte auf alle Daten zugreifen.

Unter Windows CHKDSK die Platte komplett geprüft und repariert mit bootsektor + dateisystem etc, lief 4Tage und Nächte durch.

Ende vom Lied: CHKDSK machte mir es möglich Die platte unter Windows wieder zu nutzen. Weiß aber auch nicht warum Windows kein Dateisystem mehr erkennen konnte.

eventuell kannst du ja auch prüfen ob Linux noch was mit der Platte anfangen kann, dann könntest du entweder die daten unter Linux auf ne andere Platte kopieren oder versuchen mit CHKDSK zu reparieren.
 
  • Gefällt mir
Reaktionen: 3854387
alne24 schrieb:
Weiß aber auch nicht warum Windows kein Dateisystem mehr erkennen konnte.
RAW bedeutet, dass das Filesystem entweder Windows unbekannt oder korrupt ist.
 
  • Gefällt mir
Reaktionen: areiland
@alne24 Ich meine mich erinnern zu können, im letzten Jahr versucht zu haben, die Daten mit Knoppix zu retten. So habe ich es jedenfalls schon ein paar Mal bei Problemen mit der internen Systemfestplatte meines alten Laptops gemacht. Es würde mich wundern, wenn ich es im letzten Jahr bei der externen Platte vergessen hätte.

Aber einen Versuch ist es auf jeden Fall Wert. Habe ich bislang jetzt noch nicht gemacht und hätte ich jetzt wohl auch vergessen. Danke!
 
alne24 schrieb:
Windows will ja zwingend ein Dateisystem haben , Linux ist es egal wenn es raw ist.
Auch Linux braucht zwingend ein Dateisystem welches es kennt, aber der NTFS Treiber von Linux erkennt offenbar Fehler im Dateisystem nicht so gut oder drückt da ein Auge zu, immerhin hat NTFS ja proprietär und auch nicht 100%ig öffentlich dokumentiert.

RAW ist nur die Anzeige von Windows wenn es Fehler im Dateisystem erkennt oder das Filesystem eben gar nicht kennt.
 
  • Gefällt mir
Reaktionen: areiland, alne24 und 3854387
Hallo zusammen!

Euch ist es vermutlich auch schon aufgefallen. Mal abgesehen von der FAT-Formatierung, die auch schon angesprochen wurde, weshalb hat der über 3TB große Datenträger eine MFT-Partitionstabelle? MFT wird normal nur bis maximal 2TB verwendet.
Und je nachdem wie voll die Platte schon ist oder wie weit verteilt (oder auch auch fragmentiert) die Daten auf der Festplatte sind wundern mich diese Probleme überhaupt nicht.
Und Fehlermeldung IndexerVolumeGuid könnte eben auch auf dieses Problem hindeuten.
Aber ihr seid die Profis!

Gruß Andi
 
Andi07 schrieb:
weshalb hat der über 3TB große Datenträger eine MFT-Partitionstabelle? MFT wird normal nur bis maximal 2TB verwendet.
MFT steht für Master File Table, Du verwechselst das gerade mit MBR, was eine Art der Partitionierung ist die üblicherweise nur für Platten bis 2TB nutzbar ist, aber bei mehr als 512 Byte pro logischem Sektor sind auch mehr möglich. Es ist gerade bei frühen USB Platten mit 3 oder auch 4TB gar nicht ungewöhnlich, dass deren USB-SATA Bridgechip zugleich noch eine 4k Sektoremulation hat, eben weil XP in der verbreiteten 32 Bit Version von Haus aus kein GPT unterstützt. Nachdem der normale Support für XP eingestellt wurden, ist dies bei neuen USB Platten aber weitgehend verschwunden.
 
  • Gefällt mir
Reaktionen: areiland
Hallo Holt! Hallo zusammen!

Ups, Entschuldigung, habe das tatsächlich mit MBR (Master Boot Record) verwechselt!
Aber auch gut, ein Problem weniger.

Gruß Andi
 
Pardon, dass ich mich jetzt erst wieder melde. Am Wochenende hatte ich nicht genügend Zeit für die Festplatte.

Jetzt habe ich es mit Knoppix getestet:
  • Mir wird dort nur dieser eine Ordner mit Inhalt der ersten Unterebene angezeigt, der mir auch unter Windows 10 mit Unterebene angezeigt wird. Dazu die beiden genannten Dateien "IndexerVolumeGuid" und "WPSettings.dat". Alle anderen Ordner der obersten Ebene werden mir dort nicht angezeigt.
  • Zusätzlich wurden mir dort ein Found.000 und ein FOUND.001 Ordner angezeigt. Allerdings mit kaum Inhalt. Nur wenige Dateien, etwa 100 MB Inhalt.

Unter Windows 10 wird es mir nach wie vor wie bislang angezeigt, lässt sich aber nicht öffnen. Ich sehe die oberste Ordnerstruktur. Ich sehe zudem, dass nur 709 GB von 3,63 TB frei sein sollen. Verschwunden ist also, vermute ich, noch nichts. Ich weiß nur nicht, wie ich es rekonstruieren soll.


Weiß denn niemand, wie ich dafür sorgen könnte, dass auf die Backup-FAT zurückgegriffen wird? Oder wie ich herausfinden könnte, wie ich dafür sorge? Oder gibt es sonst irgendeinen Ansatz?

Ansonsten würde ich tatsächlich wieder zu Chkdsk greifen und schauen, ob repariert/recovert werden kann. Aber irgendeine feinere Lösung wäre mir lieber.

Edit: Wenn es eine Möglichkeit gibt, speziell nach .txt-Dateien zu suchen und sie zu recovern, wäre das hilfreich. Über den Verlust aller anderen Dateitypen könnte ich in diesem Fall hinwegsehen. Aber gerade bei .txt-Dateien wüsste ich nicht, wie ich die speziell recovern sollte. Weder durch irgendwelche Programme noch durch Chkdsk, weil ich mit den Dateien in den Found-Ordnern - bislang jedenfalls - nur etwas bei größeren Dateien und anderen Formaten anfangen konnte.
 
Checkdisk recovert nichts! Die Ordner Found.000 und Found.001 sind sogar schon die Ergebnisse eines Checkdisklaufes. Wenn Checkdisk, mit dem Parameter /r ausgeführt, auf Beschädigungen trifft, dann verschiebt Checkdisk die Inhalte der betroffenen Zuordnungseinheit zunächst in einen sicheren Bereich des Datenträgers - was die Ordner Found.xxx erzeugt. Dann führt Checkdisk einen mehrfachen Schreib-/Lesetest aus, um die betroffenen Sektoren zu reaktivieren.

Alles was Checkdisk dadurch im sicheren Bereich des Datenträgers speichert, wird ohne Bezug zum vorherigen Dateinamen und ohne Bezüge zu den restlichen zugehörigen Zuordnungseinheiten gespeichert. Die so gesicherten Daten sind nur noch Fragmente der Dateien, zu denen sie mal gehörten. Diese Dateien werden also unweigerlich zerrissen, aufeinander folgende Dateifragmente müssen nicht mal zur gleichen Datei gehören, denn im Dateisystem fragmentierte Daten werden fortlaufend entsprechend ihrer physischen Position auf dem Datenträger und nicht entsprechend ihrer logischen Position gespeichert. Zudem verbleiben Dateifragmente, an deren Positionen keine Fehler gefunden wurden, in ihren Zuordnungseinheiten, aber die Bezüge zu den verschobenen Daten gehen verloren. Checkdisk zerrupft also im Zweifel den gesamten Datenbestand des Datenträgers. Das sogar dann, wenn es lediglich Dateisystemfehler gab, die Checkdisk mit nur dem Parameter /f ohne grosse Fehlbestände repariert hätte.

Das reparieren dann nicht mal mehr Testdisk und Co. Von daher ist Chkdsk /f /r nur dann eine Option, wenn man eine Komplettsicherung des Datenträgers besitzt oder aus anderen Gründen auf den Datenbestand verzichten kann.
 
Zuletzt bearbeitet: (Korrektur!)
Zurück
Oben