WinXP: Gelöschte Dateien auf Festplatte wieder herstellen

Nachtrag: Dateisystem ist FAT32

FAT32 oder NTFS?
Neu booten meint es wird sehr viel auf der Platte geschrieben. In so 
einer Situation am besten hart ausschalten und die Platte extern an nen 
anderen PC hängen. Dann per FAT32/NTFS Recovery Software rangehen.


BTW: Wenns wirklich wichtige Daten waren schickt man die HDD zu einem 
Dienstleister.

Pechvogel schrieb:
> Hallo,
>
> habe versehentlich einige wichtige große Dateien (je 50MB) gelöscht und
> den Papierkorb auch schon gelöscht. Danach keine Dateien mehr
> gespeichert und nur einmal neu gebootet.
>
> Gibt es Möglichkeit, die Dateien wieder herzustellen?

Deine Chancen stehen gut.
Es gibt diverse "undelete" Programme, früher konnte DOS das sogar 
selber.
Einfach googlen. Empfehlungen gebe ich lieber nicht, weil ich keines 
kenne.

Aber:
Bitte den PC nicht mehr einschalten.
Schließ die Platte an einen anderen Rechner an, und versuch es von dort 
aus.
Auf keinen Fall rikieren, dass irgendwas auf die Platte geschrieben 
wird.

test schrieb:
> BTW: Wenns wirklich wichtige Daten waren schickt man die HDD zu einem
> Dienstleister.

Wenn die Daten wichtig wären, würde man nicht in uC.net anfragen!

test schrieb:
> Neu booten meint es wird sehr viel auf der Platte geschrieben. In so
> einer Situation am besten hart ausschalten und die Platte extern an nen
> anderen PC hängen.

Ich vergaß zu erwähnen, dass die Platte in 4 Partitionen aufgeteilt ist. 
Ich schreibe seit Urzeiten keine Daten auf C: Die Daten lagen auf D:
Ich könnte also ein Windows-Tool installieren. DOS wäre mir auch recht.

Bei Convar gibt es ein kostenloses Tool. Ontrack kann das auch, kostet 
aber.

Recueva sollte es schaffen, das meiste zu retten.
Sonst CCleaner.
Sonst "Profi"-Tools.

K. S. schrieb:
> es geht hauptsächlich darum was Windows schreibt und nicht du.

Eben, WinXP schreibt hier nicht auf D:

Aber es gibt gute Nachrichten: Mit Recueva V1.53 konnte ich gelöschte 
Dateien auf D: sichtbar machen. WinXP scheint ALLE jemals gelöschten 
Dateien zu speichern (hier 38.365 Dateien). Mit der eingebauten Suche 
hat man die relevanten Dateien schnell gefunden.

Vorgeschichte: Ich hatte ein Verzeichnis gelöscht und mit einem 
gleichnamigen Verzeichnis mit aktuellem Inhalt überschrieben. 
Dummerweise war in dem alten Verzeichnis ein umfangreiches CAD in 4 
Versionen (4x60MB), das in dem Update nicht enthalten war.

Von Recueva wurde einzig die Version 3 grün gekennzeichnet (Zustand: 
Exzellent), war aber nach Wiederherstellung trotzdem beschädigt (CAD 
erzeugte einige Fehlermeldungen beim Laden). Konnte aber dennoch geladen 
und korrigiert gespeichert werden, eine wesentliche Baugruppe fehlte 
jedoch.

Konnte dann noch eine rot markierte Datei der Version 4 (Zustand: 
Unwiederherstellbar) wiederherstellen und wieder mit einem Satz 
Fehlermeldungen im CAD laden. In dieser Datei ist die wesentliche 
Baugruppe vollständig enthalten, so dass ich wohl aus beiden Dateien die 
letzte Version 4 restaurieren kann. Wohl ganz großes Schwein gehabt (in 
der Zeichnung stecken ca. 2 Wochen Arbeit).

Alle anderen Dateien (61) in dem Verzeichnis sind rot, einige gelb 
markiert (Zustand: Schwach oder Kritisch). Das Update des Verzeichnisses 
hat sich wohl an die gleiche Startpostion gesetzt. Grün war nur eine 
Datei von 61 Dateien. Und die war trotz grün beschädigt.

Bis dahin vielen Dank an das Forum, ganz besonders an Marek N.

Pechvogel schrieb:
> Eben, WinXP schreibt hier nicht auf D:

Sicher? Was mit dem Index-Dienst für die Dateisuche?

Pechvogel schrieb:

> Ich vergaß zu erwähnen, dass die Platte in 4 Partitionen aufgeteilt ist.
> Ich schreibe seit Urzeiten keine Daten auf C: Die Daten lagen auf D:
> Ich könnte also ein Windows-Tool installieren. DOS wäre mir auch recht.

In dem Fall musst du die Platte nicht ausbauen und kannst ein Recovery 
Tool auf die C: Partition installieren.
Stelle nur sicher, dass keine Dateien nach D: geschrieben werden, 
solange du deine Daten nicht rekonstruiert hast.

Hast du Programme oder Dienste im Hintergrund laufen, die Daten auf D: 
schreiben. Das kann auch der Browser sein, wenn der dort seinen Cache 
ablegt. Dann solltest du diese Programme beenden.

Ich habe für solche Fälle früher immer das Programm Recuva eingesetzt, 
das funktioniert gut.
https://de.wikipedia.org/wiki/Recuva

Stefanus F. schrieb:
> Sicher? Was mit dem Index-Dienst für die Dateisuche?

Kann man sich unter Windows bei etwas sicher sein?

Irgendeinen Index-Dienst habe ich mal vor Urzeiten abgestellt.
Wenn ich alle Dateien sichtbar mache, ist Root sauber.

Peter M. schrieb:
> Nun kannst Du zumindest den ersten Cluster wiederherstellen und nimmst
> einfach der Reihe nach soviele freie Cluster aus der FAT, bis die
> Dateilänge erreicht ist. Es gibt aber keine Garantie darauf, dass das
> die richtigen Cluster sind.

Sicher? M.W. steht am Ende eines jeden Clusters ein Pointer auf den 
nächsten Cluster und der kann auch irgendwo in der Pampa stehen. Ist ein 
Cluster samt Pointer überschrieben, dann ist eigentlich Ende. Wie das 
Programm auf "Schwach" oder "Kritisch" kommt, ist mir allerdings ein 
Rätsel.

Das Programm gibt sogar an, dass Cluster x, y, z von der Datei abc.def 
überschrieben wurde. Da ist schon ziemlich Hirnschmalz hinter. Trotzdem 
ist die grüne Farbe nicht viel wert, zumindest nicht in der kostenlosen 
Version.

Nano schrieb:
> Ich habe für solche Fälle früher immer das Programm Recuva eingesetzt,
> das funktioniert gut.
> https://de.wikipedia.org/wiki/Recuva

Genau das Programm in genau der Version habe ich verwendet.

Pechvogel schrieb:
> WinXP scheint ALLE jemals gelöschten
> Dateien zu speichern (hier 38.365 Dateien).

Das macht nicht WinXP, sondern das Dateisystem bzw. die Art der 
Löschung.
Bei einer normalen Löschung werden die Daten nicht komplett gelöscht, 
sondern nur die Einträge, dass die Daten noch zu den zu verwaltenden 
Daten gehören, aus dem Dateisystem entfernt.
Der freigewordene Speicherplatz wird dann zum Überschreiben freigegeben.
Ob das passiert hängt aber ganz davon ab, ob man auch wirklich neues auf 
die Platte schreibt.
Und dann kommt es noch auf die Größe der zu schreibenden Daten an. Da 
gerne zusammenhängende Blöcke verwendet werden und eine Defragmentierung 
vermieden werden sollte.

FAT32 muss man manuell defragmentieren, durch die Defragmentierung 
können die Daten auch überschrieben werden.
Bei NTFS liegt die Gefahr darin, dass es meines Wissens nach 
selbstständig die Daten defragmentiert.


> Konnte dann noch eine rot markierte Datei der Version 4 (Zustand:
> Unwiederherstellbar) wiederherstellen und wieder mit einem Satz
> Fehlermeldungen im CAD laden. In dieser Datei ist die wesentliche
> Baugruppe vollständig enthalten, so dass ich wohl aus beiden Dateien die
> letzte Version 4 restaurieren kann. Wohl ganz großes Schwein gehabt (in
> der Zeichnung stecken ca. 2 Wochen Arbeit).

Glück gehabt.
Ich rate dir dazu regelmäßige Backups zu machen.

Ebenfalls empfehlenswert ist die Verwendung eines NAS mit 
Snapshotfunktion.
Bswp. FreeNAS, das dafür verwendete ZFS Dateisystem kann snapshots 
anlegen.

Pechvogel schrieb:
> Sicher? M.W. steht am Ende eines jeden Clusters ein Pointer auf den
> nächsten Cluster und der kann auch irgendwo in der Pampa stehen. Ist ein
> Cluster samt Pointer überschrieben, dann ist eigentlich Ende. Wie das
> Programm auf "Schwach" oder "Kritisch" kommt, ist mir allerdings ein
> Rätsel.
>
> Das Programm gibt sogar an, dass Cluster x, y, z von der Datei abc.def
> überschrieben wurde. Da ist schon ziemlich Hirnschmalz hinter.

Das Programm muss einfach die derzeit verwendeten Cluster durchgehen und 
weiß somit, was überschrieben wurde.
Im nächsten Schritt kann man dann die Cluster der gelöschten Dateien 
durchgehen, die könnten dann Cluster von noch älteren Dateien 
überschrieben haben.
Durch die Zeitangabe weiß man, mit welcher Datei man anfangen muss.
Je älter die Löschung her ist und je größer die gelöschte Datei ist, 
desto schwieriger wird es.

Grün könnte bedeuten, dass alle Cluster noch nicht gelöscht und auch 
nicht überschrieben wurden.
Schwach könnte bedeuten, das einige wenige Cluster überschrieben wurde, 
aber sich die Zeiger rekonstruieren lassen, weil die geschriebenen Daten 
den Cluster nicht ausgefüllt haben.
Und kritisch, dass ziemlich viel überschrieben wurde und auch nicht mehr 
rekonstruiert werden kann, welche Cluster zu welcher Datei gehören.

Nano schrieb:
> Ich rate dir dazu regelmäßige Backups zu machen.

Das eigentliche Problem war ein Fehler beim Abschluß einer Arbeit. 
Sicher wäre ein tägliches Backup besser gewesen, was ich künftig auch 
irgendwie machen werde.

Aber was macht man, wenn jeden Abend 500 MB anfallen? Immer nur ein 
einziges Backup anzulegen (und das vom Vortag zu überschreiben) birgt 
m.E. das gleiche Risiko, durch eine falsche Organisation Dateien zu 
löschen.

Pechvogel schrieb:
> WinXP scheint ALLE jemals gelöschten
> Dateien zu speichern (hier 38.365 Dateien).

Man sollte daran denken, dass man zwar Schmuddelbilder oder 
Schmuddelvideos löschen und die Cluster überschreiben kann, die 
schmuddeligen Dateinamen kann man noch nach 10 Jahren aus dem Mülleimer 
ziehen. Habe nicht schlecht gestaunt, als da einige meiner Jugendsünden 
aufgetaucht sind. Und seltsamerweise waren eine Menge der Dateien 
grün...

Werde die Daten auf D: sichern und mal die Partition formatieren. Mal 
sehen, was Recuva dann noch findet.

Pechvogel schrieb:
> Aber was macht man, wenn jeden Abend 500 MB anfallen? Immer nur ein
> einziges Backup anzulegen (und das vom Vortag zu überschreiben) birgt
> m.E. das gleiche Risiko, durch eine falsche Organisation Dateien zu
> löschen.

Dafür wurde GIT erfunden. Das kümmert sich darum die Änderungen 
innerhalb der Dateien zu sichern. Geht gut wenn die Arbeit primär in 
Textdateien landet.
Ansonsten die bereits erwähnte Snapshotfunktion moderner Dateisysteme. 
Diese kümmert sich um geänderte Dateien als ganzes.


Weil ich glaube nicht das du tatsächlich jeden Tag 500MB Daten 
produzierst. Du wirst nur einige kB in deinem 500MB großen 
Datenverzeichnis ändern.

Nano schrieb:
> Das Programm muss einfach...

Einfach ist ein sehr relativer Begriff ;-)

Pechvogel schrieb:
> die Dateien wieder herzustellen?

Wenn es möglich ist die Daten erneut herzustellen, dann mach das doch!

Noch eine Möglichkeit wäre das Wiederherstellen, dazu kannste zB. mal 
GetDataBack ausprobieren.

Pechvogel schrieb:

> Aber was macht man, wenn jeden Abend 500 MB anfallen? Immer nur ein
> einziges Backup anzulegen (und das vom Vortag zu überschreiben) birgt
> m.E. das gleiche Risiko, durch eine falsche Organisation Dateien zu
> löschen.

Die Daten aufs NAS kopieren und dort einen snapshot erstellen.
Das geht auch automatisiert, wenn gewünscht.

Git wäre natürlich auch eine Lösung. Kommt halt auf den Anwendungsfall 
an.

test schrieb:
> Weil ich glaube nicht das du tatsächlich jeden Tag 500MB Daten
> produzierst.

Im Prinzip hast du recht. Es sind viele Ableitungen und weitere Dateien. 
Meist werden in den Ableitungen nur Kleinigkeiten geändert oder 
hinzugefügt. Dennoch ist eine neue Version entstanden. Viel Versionen, 
viel MB. Irgendwann muss man mal aufräumen und hier heißt es aufgepasst.

Bitteschön.
Being nächsten Mal einfach dad Backup einspielen ;-)

Nils P. schrieb:
> Warum benutzt Du noch ein etwa 20 Jahre altes Betriebssystem mit
> abgelaufenem Support?

Weil ich für einen offline Rechner einen Support so nötig brauche, wie 
einen Kropf am Hals. Weil ich für externe Geräte die alten 
Schnittstellen (seriell/parallel) brauche, weil ich noch Disketten und 
ZIP-Medien lesen/schreiben möchte - und min. 1000 weitere Gründe.

test schrieb:
> Weil ich glaube nicht das du tatsächlich jeden Tag 500MB Daten
> produzierst.

LoL! Du hast noch nie photographiert oder gar gefilmt!?

Wenn ich nen guten Tag habe, komm ich mit 1000 Bildern und/oder einigen 
Stunden Footage heim.

Pechvogel schrieb:
> Irgendwann muss man mal aufräumen und hier heißt es aufgepasst.

Deswegen jeden Tag nur die Änderungen zum Vortag speichern (GIT oder 
Snapshot), das braucht weniger Speicher als jeden Tag alles zu 
speichern. Und natürlich alle Backups aufheben.

Dann kannst du auch zu ner Version von vor drei Wochen zurück. Oder du 
kannst schauen was genau zwischen zwei Releases geändert wurde.

Pechvogel schrieb:
> Im Prinzip hast du recht. Es sind viele Ableitungen und weitere Dateien.
> Meist werden in den Ableitungen nur Kleinigkeiten geändert oder
> hinzugefügt. Dennoch ist eine neue Version entstanden. Viel Versionen,
> viel MB. Irgendwann muss man mal aufräumen und hier heißt es aufgepasst.

Dann hast du doch evtl. auch noch die internen Backupdateien.
Die Pfade kann man da trennen von denen wo man abspeichert.

Glück hast du, weil du keine SSD hast.

Marek N. schrieb:
> Bitteschön.
> Being nächsten Mal einfach dad Backup einspielen ;-)

Hat er doch gemacht :-(
Nur das falsche.

Marek N. schrieb:
> LoL! Du hast noch nie photographiert oder gar gefilmt!?
>
> Wenn ich nen guten Tag habe, komm ich mit 1000 Bildern und/oder einigen
> Stunden Footage heim.

Für Profis gelten andere Gesetze.
Nicht die Menge macht es!
In der Begrenzung liegt der Meister! (Goethe)

Peter M. schrieb:
> Nein. Die Cluster enthalten nur die Daten der Datei, keine "Pointer auf
> Cluster".

OK, da habe ich offensichtlich was verwechselt. Asche auf mein Haupt. 
Hatte mich vor Jahren mal mit dem Dateisystem von Disketten beschäftigt, 
dort existiert ebenfalls dieses FAT-Array über mehrere Sektoren.

michael_ schrieb:
> Dann hast du doch evtl. auch noch die internen Backupdateien.

Was verstehst du unter "internen Backupdateien"?

Am Projektende (war heute) wird Ordnung geschaffen, d.h. nicht mehr 
relevante Dateien und Verzeichnisse werden gelöscht. Auch entstehen 
immer mal wieder gleiche Dateien oder Dateien mit unterschiedlichem 
Namen aber gleichem Inhalt. Unter anderem weil andere Personen mit 
werkeln.

Heute nun in einem neuen Verzeichnis alles neu organisiert und gruppiert 
und dann das alte Verzeichnis mit dem ganzen Müll in den Mülleimer. Erst 
bei der Sicherung auf ein externes Medium ist aufgefallen, dass das 
Schreiben verdammt schnell von statten ging. Kein Wunder, wenn 90% der 
Datenmenge fehlte.

M.E. war das ein Fehler beim Aufräumen. Ich war sicher, dass alles 
vollständig ist. Gemein war, dass die verloren gegangen CAD-Zeichnungen 
schon länger nicht mehr benutzt wurden, da wir seit Wochen nur noch mit 
den Ableitungen arbeiten. Dass die ursprünglichen CAD-Dateien (mit allen 
Baugruppen) noch irgendwo in den Tiefen der Verzeichnisse schlummern, 
war nicht mehr richtig gegenwärtig. Ob dagegen wirklich ein Kraut 
gewachsen ist?

Selbst wenn man jeden Tag ein neues Backup macht, irgendwann nach 
Projektende vernichtet man doch den ganzen Rattenschwanz, oder stapelt 
ihr die Platten im Keller?

Pechvogel schrieb:
> noch irgendwo in den Tiefen der Verzeichnisse schlummern, war nicht mehr
> richtig gegenwärtig. Ob dagegen wirklich ein Kraut gewachsen ist?

Ein richtiger Dateimanager (TotalCommander und Co.) hilft ungemein wenn 
man sich erstmal in die Nutzung eingearbeitet hat.

Das Windows eigene Bildchenschiebeprogramm erschwert die effektive 
Arbeit ungemein.

Pechvogel schrieb:
> Am Projektende (war heute) wird Ordnung geschaffen, d.h. nicht mehr
> relevante Dateien und Verzeichnisse werden gelöscht. Auch entstehen
> immer mal wieder gleiche Dateien oder Dateien mit unterschiedlichem
> Namen aber gleichem Inhalt. Unter anderem weil andere Personen mit
> werkeln.

Dann schau dir mal eine Versionsverwaltung an.
Das muss nicht unbedingt git sein.
Wenn die CAD Anwendung überwiegend Dateien in einem binären Format 
erstellt, dann gibt es dafür auch Versionsverwaltungen, die für solche 
prädestiniert sind. Git ist mehr für Textdateien, kann aber auch für 
binäre Dateien missbraucht werden.
https://de.wikipedia.org/wiki/Versionsverwaltung

Pechvogel schrieb:
> michael_ schrieb:
>> Dann hast du doch evtl. auch noch die internen Backupdateien.
>
> Was verstehst du unter "internen Backupdateien"?

Wo es automatisch aller xxx Minuten speichert.

Bei EAGLE sind es statt .brd dann .b#1 Dateien.
Die Tiefe und Zeit kann man einstellen.

Für KiCAD Dateien ist git übrigens sehr gut geeignet, da das Format von 
KiCAD reine Textdateien sind.
Aber vielleicht verwendest du etwas anderes.

Vielen Dank für die Tips bzgl. Versionsverwaltungen. Ich mache solche 
Projekte nur ab und zu und dann sind sie in der Regel recht 
überschaubar. Ich weiß nicht, ob so eine Versionsverwaltungen für mich 
Sinn macht. Werde mir das aber mal näher anschauen.

michael_ schrieb:
>> Was verstehst du unter "internen Backupdateien"?
> Wo es automatisch aller xxx Minuten speichert.

Ach so. Hier wird eine einzige Backup-Datei erstellt, aber nicht 
automatisch. Das CAD läuft hier seit Jahren absolut zuverlässig, noch 
nie einen Absturz gehabt. Selbst nach Sleep oder Hibernate keinerlei 
Probleme. Ich speichere lieber manuell nach Bauchgefühl.

Peter M. schrieb:
> Vollkommen richtig. Besonders Grün hat gar nichts zu bedeuten. :)

Stimmt leider :(

Habe noch bisschen mit Recuva "gespielt", irgendwie hält das Programm 
nicht ansatzweise, was es verspricht. Habe bestimmt 20 grün markierte 
Dateien (grün = unbeschädigt, alle Cluster vorhanden) wiederhergestellt, 
keine einzige Datei (*.mp3, *.mp4, *.avi, *.pdf, *.doc, *.zip, *.jpg, 
*.gif) war lauffähig :(

Habe dann nach Neustart eine *.pdf Datei im Mülleimer versenkt und 
gelöscht, die Datei war dann in Recuva rot markiert (nicht wieder 
herstellbar). Kommentar: Diese Datei wurde mit "D:\Recycled\desktop.ini" 
überschrieben. Recycled ist zwar vorhanden, aber leer. Also wenn das 
schon nicht funktioniert, kann eigentlich nichts funktionieren.

Bei einem weiteren Test wurde die eben gelöschte Datei durch eine Datei 
überschrieben, die vor ca. 2 Jahren gelöscht wurde. Das Tool scheint mir 
mit heißer Nadel gestrickt. Unter WinXP SP3 und FAT32 eigentlich 
wertlos. Schade, denn das Tool ist wirklich nett gemacht und zudem in 
deutscher Sprache.

Gerettet hat die Sache mein wirklich erstklassiges CAD, dessen 
Dateistruktur offensichtlich so genial ist, dass es auch beschädigte 
Dateien einlesen kann und dann nur die unbeschädigten Bauteile darstellt 
und man selbige wieder abspeichern kann. Da haben die Entwickler 
wirklich an alles gedacht. Alle anderen Programme melden eine 
beschädigte Datei und weisen selbige ab, oder stürzen ohne jegliche 
Meldung ab.

Nachtrag: Gibt es für WinXP SP3 und FAT32 ein Tool, das wirklich 
funktioniert? Oder manipuliert WinXP beim Löschen die FAT, so dass eine 
Wiederherstellung grundsätzlich nicht möglich ist?

> Peter M. schrieb:
>> Vollkommen richtig. Besonders Grün hat gar nichts zu bedeuten. :)
> Stimmt leider :(

KOMMANDO ZURÜCK !

Habe die Daten von D: gesichert und die Partition unter WinXP neu 
formatiert (keine Schnellformatierung). Nun findet Recuva 0 Dateien und 
schlägt eine "Tiefensuche" vor, die allerdings mehrere Stunden dauern 
könnte. Interessehalber mal gestartet und siehe da, nach ca. 1 Stunde 
sind trotz Neuformatierung wieder alle 38.365 Dateien da. UNGLAUBLICH!

Und jetzt kommt's: Nun funktioniert das mit der grünen Markierung!
6 Wiederherstellungen (*.pdf, *.png, *.zip, *.jpg) und 6 Volltreffer!

Wenn das die Leut bei Ebay wüssten, die dort ihre "frisch formatierten" 
(= gelöschten) Festplatten anbieten ...

Pechvogel schrieb:
> Wenn das die Leut bei Ebay wüssten, die dort ihre "frisch formatierten"
> (= gelöschten) Festplatten anbieten ...

Wenn man seine Dateien löschen will, dann macht man das besser mit Tools 
wie Eraser.
Das überschreibt die Festplatte auf Wunsch auch mehrmals mit 
randomdaten.

Manche Antivirensoftware liefert übrigens gleich eine Shreddersoftware 
mit.
AVG installiert so eine, damit kann man die Dateien auch richtig 
shreddern bzw. löschen.

Hallo Pechvogel,

hatte die Diskussion schon einmal in einem anderen Tread. Bei mir und 
auch bei meinen Bekannten ist GetDataBack komplett durchgefallen. Finden 
nur Schrott, kann nich vernünftig Sectoren zusammen bauen.
Ich habe mit 'R-Studio' die besten Erfahrungen gemacht. Bis auf wirklich 
überchriebene Sectoren stellte mir R-Studio alles komplett her. Man kann 
sogar die komplette Platte nach Strings, Inhalten, ect durchsuchen.

Andere Möglichkeit ist über Linux. Aber nicht Ubuntu, sondern Suse. Hier 
über Testdisk, ect.

Solltest Du bereits Schreibversuche auf die betreffende HDD gemacht 
haben, wird's schwierig.

Pechvogel schrieb:
> KOMMANDO ZURÜCK !
>
> Habe die Daten von D: gesichert und die Partition unter WinXP neu
> formatiert (keine Schnellformatierung).

Pechvogel schrieb:
> Wenn das die Leut bei Ebay wüssten, die dort ihre "frisch formatierten"
> (= gelöschten) Festplatten anbieten ...

Man tut doch in so einen Fall nicht formatieren, sonder neu 
partitionieren.
Da ist erst mal alles weg. Für Normalos.
Und dann gibt es genug Tools, um bestimmte Bereiche ganz sicher zu 
löschen.

Peter M. schrieb:
> Das ist ein Indiz dafür, dass das Hauptverzeichnis mal durch
> Defragmentierung wegbewegt wurde, so dass es von der Formatierung nicht
> betroffen war. Damit waren nach der Formatierung immer noch genauso
> viele Verzeichniseinträge vorhanden wie vorher.

Du meinst, meine Partition hatte einen Hau weg?
Machte im praktischen Betrieb jedoch keinerlei Probleme.

In der Tat hatte ich den vielen Jahren paar mal die WinXP eigene 
Defragmentierung laufen lassen. Sollte man hier lieber die Finger von 
lassen?

Habe es mittlerweile durch alle möglichen Windows-Tools geschafft, die 
Directory von den 38.365 Dateien zu befreien. Eine einzige Datei hält 
sich jedoch hartnäckig (Bild). Diese Datei mit 3,17 GB habe ich niemals 
erstellt, ebenso den dubiosen Dateinamen. Auch sind Erstellungs- und 
Änderungsdatum nicht ganz von dieser Welt. Unter Windows existiert diese 
Datei nicht. Windows meldet auch keinerlei Fehler auf dieser Partition.

Bevor ich nun meine Daten wieder auf diese Partition zurück kopiere, 
hätte ich diese Leiche (oder was das ist) gerne weg. Oder ist das ein 
Bug von Recuva?

Ihr solltet erst mal die Komentare zu den 'Free' Downloads von 'Recuva' 
lesen

siehe:
Link:https://www.heise.de/download/product/recuva-43395

Was habt ihr dagegen, wenn ein Rettungsprogram wie R-Studio verschiedene 
Wege aufzeigt. Hier habe ich auch Ext4 Daten retten können.

Er schreibt ja selbst, dass Recuva nichts retten konnte und nur Quatsch 
angezeigt hat.

Unter Linux Testdisk versuchen. Ich würde aber, wenn's wichtig ist die 
Platte 'clonen, und mit dem Clon die Rettung versuchen. Dann hat man 
immer noch das 'Original', worauf man wieder setzen kann. Jeder 
Recuver-Versuch auf 'dieser Platte' schrottet Dir noch mehr.

CC-Cleaner taugt genauso wenig !!

Sorry, habe auch schon Datenrettung machen müssen. Ich weiß wovon ich 
rede / schreibe.

Beleidigungen bitte vermeiden. Danke.

Peter M. schrieb:
> Du könntest folgendes probieren:
>
> Formatiere Deine nun leere D-Partition mit NTFS und schreibe mit h2testw
> die Partition voll. Dann formatierst Du die D-Partition wie von Dir
> gewünscht.

Genau das hatte ich gemacht (nur mit FAT32), dann die Dateien gelöscht 
und die Partition nochmals formatiert, dann blieb diese Leiche übrig. 
Nachdem ich nun nochmal die Partion mit h2testw vollgeschrieben habe, 
ist die Leiche nun weg. Werde die Testdateien löschen und dann meine 
Daten zurück schreiben. Dann mal schauen, was Recuva dazu sagt.

Thomas schrieb:
> Er schreibt ja selbst, dass Recuva nichts retten konnte und nur Quatsch
> angezeigt hat.

Stimmt, mit dem "Schnellscan" war das so. Aber nach der Formatierung der 
Partition und dem "Tiefenscan" hat das perfekt funktioniert. Nur wer 
formatiert seine Platte vor der Datenrettung? Welches Ergebnis der 
Tiefenscan gleich zu Anfang gebracht hätte, steht in den Sternen.

Peter M. schrieb:
> Vielleicht bleibst Du auch bei NTFS als Dateisystem.
> Das ist robuster als FAT32.

Als ich vor Urzeiten von Win98 nach WinXP umstieg, gab es irgendwelche 
Gründe, bei FAT32 bleiben. Unter anderem hat mich damals gestört, dass 
es kein zurück mehr gab, wenn man mal auf NTFS umgestiegen ist.

Das Problem bei Fat32 ist, dass Dateien max 4GB groß sein dürfen. Und 
die Rechteverwaltung so nicht möglich ist. In einer modernen Umgebung 
ist Fat32 adacta. NTFS ist wesentlich 'stabiler' und Videodateien > 4GB 
sind möglich,.

Peter M. schrieb:
> Da bei Dir "D:" nur Datenpartition ist, kannst Du munter hin- und
> herformatieren.

Sicher? Ich meine mich zu erinnern, dass ich die Partition D: mal nach 
NTFS umformatiert hatte (beim Grabben störte die 4GB Grenze), danach 
wurde mir FAT32 nicht mehr angeboten und ich konnte die Platte neu 
partitionieren und formatieren. Und danach WinXP neu aufsetzen. Kann 
mich aber auch irren, ist schon sehr lange her. Auf jeden Fall werde ich 
es an dem Rechner nicht ausprobieren.

Thomas schrieb:
> Und die Rechteverwaltung so nicht möglich ist.
> In einer modernen Umgebung ist Fat32 adacta.

Eine Rechteverwaltung an einem ausschließlich von mir genutzten offline 
Rechner wäre so unnütz wie ein Kropf an Hals.

Peter M. schrieb:
> Nein, kein Bug. Wenn irgendwo Daten stehen, die aussehen wie ein
> Unterverzeichnis mit einer Bytefolge, die aussieht wie ein Eintrag, muss
> Recuva das für eine Datei halten.

Das mag so sein, nachdem ich die Partition mit h2testw vollgeschrieben 
hatte, war die "Datei-Leiche" weg.

Mittlerweile habe ich meine Dateien wieder zurückgeschrieben, die 
Tiefensuche sieht nun gut aus (Bild). Wobei mir Windows auf der 
Partition 27.660 Dateien (in 2.684 Ordnern) anzeigt, Recuva findet 
27.710 Dateien, also 50 Dateien mehr. Auf der Partition befinden sich 
keine versteckten Dateien.

Auf zwei weiteren Partitionen fanden sich ebenfalls Altlasten im 
5-stelligen Bereich, dort habe ich bei der Gelegenheit ebenfalls 
ausgemistet. Die Tiefensuche liefert bei beiden Partitionen die gleichen 
0 Fundstellen wie im Bild.

Werde immer mal wieder eine Datei im Mülleimer versenken, dann den 
Mülleimer leeren und schauen, ob mit Recuva eine Rettung erfolgreich 
ist. Denn der Nutzen dieses Tools ist ja sehr umstritten. Könnte mir 
aber auch vorstellen, dass dieses Tool bei einem beschädigten 
Dateisystem nicht mehr richtig funktionieren kann.

Nebenbei: Kann jemand mit dem Bildchen links oben was anfangen? Das 
gelbe sieht mir nach einer Semmel auf einem Eierbecher aus und das graue 
dahinter ist ein altes Telefonmodem? Oben rechts entdecke ich noch eine 
Birne. Entdeckt jemand eine Botschaft?

Pechvogel schrieb:
> Sicher? Ich meine mich zu erinnern, dass ich die Partition D: mal nach
> NTFS umformatiert hatte (beim Grabben störte die 4GB Grenze), danach
> wurde mir FAT32 nicht mehr angeboten

Ist aber eine rein "politische" Entscheidung von Microsoft, genau wie 
die maximale Größe des FAT32 Dateisystem. Die haben diese Limitierung 
ohne technischen Zwang extra in die Software eingebaut.
Mit jeder nicht Microsoft Formatsoftware ging das alles natürlich 
weiterhin.

Wobei für interne Laufwerke NTFS natürlich sinnvoll ist.
Bei externen Datenträgern ist NTFS oft nervig und stört.

test schrieb:
> Ist aber eine rein "politische" Entscheidung von Microsoft...

So habe ich das auch im Hinterkopf bzgl. dem nicht mehr anbieten von 
FAT32 nach dem Wechsel auf NTFS. Nach dem Motto: Der Weg geht nach vorne 
- und nicht zurück. Diese Art der Bevormundung geht gar nicht.

Rufus Τ. F. schrieb:
> FAT32 braucht man nur zum Tausch von Daten mit Systemen, die kein NTFS
> lesen oder schreiben können. Aber das sind, von Microcontrollern mal
> abgesehen, immer weniger.

Immer weniger können immer noch verdammt viel sein ;-)

Abschließend noch einen 8GB USB-Stick nach der gleichen Methode 
aufgeräumt, auch hier fanden sich unglaubliche Altlasten. Nach dem 
Zurückschreiben der Daten fand Recuva 337 Dateien und Windows 329 
Dateien. Auf dem Stick befinden sich keine versteckten Dateien. Eine 
ähnliche Abweichung war bei der Partition D: meiner Platte auch 
aufgetreten.

Weitere Fragen bleiben:

1. Nach dem Formatieren des USB-Sticks tauchen Dateinamen von gelöschten 
Dateien vollständig auf, also ohne gelöschten ersten Buchstaben.

2. Es werden Dateinamen gefunden, die nicht den Konventionen für 
Dateinamen entsprechen (Bild).

3. Offensichtlich kann eine Datei wiederhergestellt werden, deren 
Dateiname nicht mehr vorhanden ist (Bild). Das markierte Video 
[000002.mp4] wurde vor Jahren gelöscht, konnte aber wiederhergestellt 
werden und war zu 100% lauffähig. Woran kann Recuva den Datentyp 
erkennen?

4. Was macht eigentlich die Nicht-Schnell-Formatierung unter Windows, 
wenn eine gelöschte Datei nach der Formatierung mit Dateinamen komplett 
lesbar und wiederherstellbar bleibt? Wenn die Nicht-Schnell-Formatierung 
schon nichts leistet, was leistet dann erst die Schnellformatierung?

5. Eine Datei überschreibt beim Speichern einen Datenbereich, Einträge 
in der FAT und den Dateinamen einer älteren Datei, so meine Theorie. 
Kann es sein, dass Dateinamen niemals überschrieben werden? Denn wie 
kann sich sonst eine 5-stellige Anzahl an alten und uralten Dateinamen 
ansammeln?

Rufus Τ. F. schrieb:
> Nein. Die 4-GB-Größenbeschränkung ist eine technische Beschränkung, die
> kann nicht ohne eine komplette Änderung des Dateisystems umgangen
> werden.

Ja, die 4GB meinte ich auch nicht, ich meinte schon wirklich die max. 
Dateisystemgrösse (also Größe der Partition).

Die Beschränkung der Dateigröße ist dann tatsächlich ein Grund für den 
Wechsel.

Pechvogel schrieb:
> Weitere Fragen bleiben:
>
> 1. Nach dem Formatieren des USB-Sticks
.......


Nochmal, ganz langsam, formatieren löscht keine Daten!
Nur die Zusammenhänge sind weg.

michael_ schrieb:
> Nur die Zusammenhänge sind weg.

Nicht mal die sind nach dem Formatieren weg, sonst könnte ich ein vor 
Jahren gelöschtes Video nicht problemlos wiederherstellen.

Eben auf der Partition D: einem dortigen Photoalbum ca. 100 Bilder 
hinzugefügt und rein interessehalber mal Recuva gestartet. Dies meldet 
nun ca. 100 gelöschte uralte Bilder aus diesem Photoalbum, die aber in 
dem Photoalbum noch vorhanden sind.

Diese gelöschten Bilder sind dann allesamt rot markiert (nicht 
wiederherstellbar), da mit einem anderen uralten Bild überschrieben (?) 
Gleichzeitig wird mir aber bei der Markierung eines nicht 
wiederherstellbaren Bildes sofort eine Vorschau angezeigt und das Bild 
wird fehlerfrei wiederhergestellt.

Hmmm - also doch eher mit heißer Nadel gestrickt?

Den Kropf am Hals kannst Du sehen, wie Du willst. Es macht keinen Sinn 
mehr mit Fat 32.

Ich kann mir nicht vorstellen, dass es noch zwingend Gründe gibt für 
Fat32. Selbst Linux kann mit NTFS umgehen.

Pechvogel schrieb:
>
> 3. Offensichtlich kann eine Datei wiederhergestellt werden, deren
> Dateiname nicht mehr vorhanden ist (Bild). Das markierte Video
> [000002.mp4] wurde vor Jahren gelöscht, konnte aber wiederhergestellt
> werden und war zu 100% lauffähig. Woran kann Recuva den Datentyp
> erkennen?

Am Dateiheader, sofern vorhanden.
Die Dateiendung selbst ist nicht zwangsläufig nötig, um den Dateityp zu 
bestimmen.

Thomas schrieb:
> Ich kann mir nicht vorstellen, dass es noch zwingend Gründe gibt für
> Fat32. Selbst Linux kann mit NTFS umgehen.

In der Unterhaltungsindustrie kommt man meistens nicht drumherum. Da ist 
dann NTFS-Unterstützung mangels Geldüberweisung nicht lizensiert.

Peter M. schrieb:
> Formatierung ist kein Mittel zur Datenlöschung. Formatierung setzt die
> Metastrukturen zurück.

Der Pechvogel ist zwar schon uralt, hat es in der Zwischenzeit nicht 
mitbekommen.
Und erfreut sich tierisch, wenn irgendein Programm Dateifragmente oder 
Dateinamen ausspuckt.
Das daraus keine komplette Dateien entstehen können, ignoriert er.

Ist aber bekannt.

Peter M. schrieb:
> hast Du bei FAT32
> Unterverzeichnisse, die eigenen Speicherplatz beanspruchen.

D.h. ein Recovery-Tool kann bei FAT32 nicht sicher funktionieren?

Bei Wikipedia findet sich zu Recuva: "Gelobt wurde die sehr gute 
Datenrettung auf NTFS-Festplatten, bemängelt wurde die Rettung auf 
FAT-Festplatten sowie auf externen Datenträgern."
https://de.wikipedia.org/wiki/Recuva#Testberichte

Bei Recuva habe ich es erlebt, dass rot wiederherstellbar war und grün 
eben nicht. Also genau andersrum, wie es eigentlich sein sollte. Und 
allerlei Meldungen (Cluster wurden überschrieben), die einfach falsch 
waren.

Vielen Dank an Peter M. für seine Erklärungen und seine Mühe!

Peter M. schrieb:
> und das geht bei fragmentierten Dateien schief.

Ok, das leuchtet ein. Dann ist also alles entscheidend, ob die Daten 
beim Schreiben in einem Rutsch (unfragmentiert) abgelegt werden konnten.

Wird eigentlich ein großer unbeschriebener Datenträger erst einmal 
komplett durch beschrieben und erst dann wird wieder am Anfang 
angefangen und die durch zwischenzeitliches Löschen frei gewordenen 
Plätze neu beschrieben, wodurch sich dann der Flickenteppich ergibt? 
Oder achtet man bei jedem Schreiben darauf, am Anfang der Platte keine 
freien Plätze entstehen zu lassen?

Peter M. schrieb:
> Das ist bei einer Löschung unter NTFS anders.

DAS wäre dann tatsächlich mal ein Grund, auf NTFS umsteigen.

Peter M. schrieb:
> Ich freue mich. :)

Na das freut mich ebenso. Kann ich doch als Einäugiger (unter den 
Blinden in meinem Umfeld) einiges Fachwissen an Land ziehen ;)