mikrocontroller.net

Forum: PC Hard- und Software WinXP: Gelöschte Dateien auf Festplatte wieder herstellen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Vielen Dank

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Dateisystem ist FAT32

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Undelete (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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!

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kurt A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Convar gibt es ein kostenloses Tool. Ontrack kann das auch, kostet 
aber.

Autor: Marek N. (bruderm)
Datum:

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

Autor: K. S. (the_yrr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pechvogel schrieb:
> Ich schreibe seit Urzeiten keine Daten auf C: Die Daten lagen auf D:

es geht hauptsächlich darum was Windows schreibt und nicht du. wenn du 
es kannst mounte diese partition als read only, hab leider keine Ahnung 
wie das in XP geht.

als software kenn ich

testdisk + photorec als konsolenprogramm und umsonst
easeus hat nen data recovery wizard
autopsy ist auch eine data recovery suite

wenn es wirklich wichtig ist würde ich die Partition vorher kopieren, 
z.b. mit ddrelease oder hddrawcopy für windows, unter linux dd oder 
ddrescue glaub ich und dann alle weiteren versuche mit dem image machen, 
ich mounte images mit daemontools lite, aber da gibt es genug auswahl an 
software.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das klingt so, als würden diese bunten Markierungen von der Software 
ausgewürfelt ...

Autor: Stefanus F. (stefanus)
Datum:

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

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

: Bearbeitet durch User
Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Rufus,

Rufus Τ. F. schrieb:
> Das klingt so, als würden diese bunten Markierungen von der Software
> ausgewürfelt ...

Vollkommen richtig. Besonders Grün hat gar nichts zu bedeuten. :)

FAT32 verwaltet ja den Speicherplatz wie viele andere Dateisysteme auch 
in Häppchen, genannt "Cluster".
FAT-Dateisystem verwalten Dateien mit Hilfe von Verzeichniseinträgen und 
einer Nachfolgertabelle, genannt "FAT".
Der Verzeichniseintrag zeigt auf den ersten Cluster, die FAT zeigt die 
Nachfolgecluster an.

Bei gelöschten Dateien hast Du unter FAT32 immer noch den 
Verzeichniseintrag (der erste Buchstabe wird überschreiben meine ich). 
Aufgrund der Angabe der Dateilänge kennst Du nun auch die Anzahl der 
Cluster:

nr_cluster=Dateilänge/ClustergrößeInBytes

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.
Ist das Dateisystem fragmentiert, kannst Du auf diesem Weg auch Cluster, 
die zu anderen Dateien gehörten, aufsammeln. :=)
Ergo kannst Du kurze Dateien, sofern der Cluster nicht schon durch eine 
andere Datei in Beschlag genommen wurde, immer wiederherstellen.

Mehr geht einfach nicht ohne Kenntnis des Dateityps und des Aufbaus der 
Inhalte der Datei.
Zwischenzeitliches Schreiben durch andere Dateien eliminiert auch die 
gelöschten Inhalte.

Um hier eine höhere Erfolgswahrscheinlichkeit zu haben, müsstest Du die 
Art der Datei und ihren inneren Aufbau kennen, aber mir ist kein 
Programm bekannt, das so vorgeht.

2001 bekam ich ein Festplatte eines Kollegen, die "ein wenig 
durcheinander geraten war".
Er hatte alle Hochzeitseinladungen verschickt aber infolge seines 
logischen Plattenschadens die Planungsdatei in Excel, die auch die 
Gästeliste enthielt, verloren. Das betroffene Dateisystem war eines von 
den beiden FAT-Varianten.

Der Anfang der Excel-Datei war schnell gefunden, aber das naive 
Clusterverketten, was die Rettungsprogramme wohl betreiben, 
funktionierte nicht, die Datei war nicht zu öffnen.

Letzten Endes konnte ich mit einem Diskeditor und einem scharfen Blick 
auf die Sektoren bzw. Cluster diese Datei auch wiederherstellen - sonst 
aber nichts! Egal, die Hochzeit war gerettet.

: Bearbeitet durch User
Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nano schrieb:
> Das Programm muss einfach...

Einfach ist ein sehr relativer Begriff ;-)

Autor: Gurgl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

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

Autor: Nils P. (torus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Warum benutzt Du noch ein etwa 20 Jahre altes Betriebssystem mit 
abgelaufenem Support?

Und wie immer gilt: Kein Backup, kein Mitleid.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marek N. (bruderm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitteschön.
Being nächsten Mal einfach dad Backup einspielen ;-)

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marek N. (bruderm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Pechvogel,

Pechvogel schrieb:
> Sicher?

Ja. :)

> 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

Nein. Die Cluster enthalten nur die Daten der Datei, keine "Pointer auf 
Cluster".
Die FAT enthält Cluster-Nummern.
Die FAT ist nichts anderes als ein großes Array, dass einer 
Cluster-Nummer die Folgenummer, das Ende der Datei oder den Status 
"defekt" zuweist.

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: test (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

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

Autor: Weingut P. (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GetDataBack gibts für FAT und NTFS, hatte vor Jahren mal Bedarf und 
hatte damals diverse Programme ausprobiert, diese waren bei mir die 
Besten. Nicht umsonst aber auch nicht sehr teuer und wenn die Daten 
wichtig waren allemal ihr Geld wert.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ...

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Pechvogel,

Pechvogel schrieb:
> Nachtrag: Gibt es für WinXP SP3 und FAT32 ein Tool, das wirklich
> funktioniert?

Die Antwort dazu finden Menschen, die lesen können und wollen.

> Oder manipuliert WinXP beim Löschen die FAT,

Der Dateisystemtreiber für FAT32 muss die entsprechenden FAT-Einträge 
wieder auf "frei" setzen, damit die betroffenen Cluster bei neuen 
Schreibvorgängen wieder zur Verfügung stehen.

> so dass eine
> Wiederherstellung grundsätzlich nicht möglich ist?

Die Antwort dazu finden Menschen, die lesen können und wollen.

Pechvogel schrieb:
> 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!

Zufall. 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.

Dein Jubel ist vollkommen unbegründet.
Die Antwort dazu finden Menschen, die lesen können und wollen.

Ich find's übrige Scheisse, wenn Anfrager meine Antworten nicht lesen.

: Bearbeitet durch User
Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas schrieb:
> 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.

Es werden keine Sektoren zusammengebaut, sondern Cluster.

> Ich habe mit 'R-Studio' die besten Erfahrungen gemacht. Bis auf wirklich
> überchriebene Sectoren stellte mir R-Studio alles komplett her. Man kann

Schon wieder die Werbung für R-Studio?
Das ist eine wirklich beeindruckende Software, die 26x mehr Daten aus 
dem Datenträger herausholt, als überhaupt vorhanden sind:

https://www.computerbild.de/artikel/cb-Tests-Software-Datenretter-Haage-Partner-R-Studio-5.1-5246925.html

Chapeau, muss man da einfach mal sagen!

> sogar die komplette Platte nach Strings, Inhalten, ect durchsuchen.

Kann auch jeder kostenlose 0815-Diskeditor.

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

Wie meinen? Testdisk läuft auch unter Fensterbetriebssystemen.

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

Immerhin, eine zutreffende Ausage, gut!

: Bearbeitet durch User
Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Pechvogel,

Pechvogel schrieb:
> 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?

Nein. Bei einer Neuformatierung müssen die beiden FATs überschrieben 
werden um jeden Cluster freizugeben. Dann muss entweder im 
Wurzelverzeichnis jeder Eintrag gelöscht und das Wurzelverzeichnis auf 
die Ausgangsgröße verkürzt werden. Vermutlich schreibt der Treiber das 
Wurzelverzeichnis einfach neu.

Bei der letzteren, wahrscheinlicheren Variante verliert Recuva aber alle 
Einträge aus dem Wurzelverzeichnis auf der Länge, auf der der Treiber 
das Wurzelverzeichnis nullt. Passiert aber gar nichts, liegt das 
Wurzelverzeichnis migrationsbedingt schon irgendwo anders auf der 
Festplatte und ist vom Neuschreiben des Wurzelverzeichnis nicht 
betroffen.

Nein, Deine Partition hat keinen 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?

Ich glaube, die Drittanbietersoftware ist hier besser. Die 
Defragmentierung erhöht ja auch die Chancen auf Wiederherstellung, weil 
die Daten in aufeinander folgenden Cluster zu liegen kommen.

>
> 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?

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.

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.

Alternativ kannst Du die D-Partition auch mit einem Tool Deiner Wahl 
oder einfach unter Linux nullen und dann neu formatieren.
Dann sollte Recuva diesen Eintrag auch nicht mehr finden.

Vielleicht bleibst Du auch bei NTFS als Dateisystem. Das ist robuster 
als FAT32.

: Bearbeitet durch User
Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pechvogel schrieb:
> 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 betrifft die Betriebssystempartition, eventuell auch die 
Bootpartition.
Da bei Dir "D:" nur Datenpartition ist, kannst Du munter hin- und 
herformatieren.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Warum auch sollte man FAT32 verwenden wollen, wenn man es denn nicht 
muss?

Es ist inhärent instabiler, es hat die Dateigrößenlimitierung, es 
unterstützt keine transparente Dateiverschlüsselung oder -Komprimierung 
...

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.

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jay W. (jayway)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pechvogel schrieb:
> 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?

Sieht eher nach einem gelben Helm und einer dahinter stehenden 
Festplatte aus. Die Birne ist, glaube ich, das Logo von Piriform.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
test schrieb:
> Ist aber eine rein "politische" Entscheidung von Microsoft, genau wie
> die maximale Größe des FAT32 Dateisystem.

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

Im Directoryeintrag wird die Dateigröße in Bytes gespeichert, und dafür 
stehen vier Bytes zur Verfügung. Wollte man das ändern, müssten die 
Directoryeinträge anders aufgebaut werden.

Die 32-GB-Größenbeschränkung hingegen ist in der Tat reine Willkür, und 
es gibt ausreichend viele alternative Formatierungsprogramme oder 
Betriebssysteme, die sich nicht um diese Beschränkung kümmern. Windows 
selbst weigert sich nur bei der Formatierung, beim normalen Betrieb 
(lesen und schreiben) hat es diese Beschränkung nicht.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Pechvogel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: test (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pechvogel schrieb:

> 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.

Lange Dateinamen werden doppelt gespeichert, einmal im DOS8.3-Stil und 
einmal lang. Vermutlich wird nur der erste Buchstabe im DOS-Eintrag 
gelöscht.

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

Das passiert bei einem defragmentierten Unterverzeichnis, wenn die 
spekulativ erratenen Folgecluster die falschen sind.

>
> 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?

Durch Blick in den Header. Hab's nachgelesen, Recuva versteht sich auf 
ein paar Dateitypen und analysiert den Header.

> 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?

Formatierung ist kein Mittel zur Datenlöschung. Formatierung setzt die 
Metastrukturen zurück.

>
> 5. Eine Datei überschreibt beim Speichern einen Datenbereich, Einträge
> in der FAT

Ja.

> und den Dateinamen einer älteren Datei, so meine Theorie.

Nein. Nicht zwangsläufig.

> Kann es sein, dass Dateinamen niemals überschrieben werden? Denn wie
> kann sich sonst eine 5-stellige Anzahl an alten und uralten Dateinamen
> ansammeln?

Nein. Anders als bei NTFS mit seiner MFT, wo jede Datei ihren Eintrag 
drin hat und gelöschte Einträge ohne Einschränkungen wieder dem nächsten 
Schreibvorgang zur Verfügung stehen, hast Du bei FAT32 
Unterverzeichnisse, die eigenen Speicherplatz beanspruchen. Gelöschte 
Directory-Einträge können bei Anlage neuer Dateinamen nur verwendet 
werden, wenn sie sich innerhalb desselben Unterverzeichnis befinden. 
Dementsprechend können viele Directory-Leichen in anderen 
Verzeichnissen, wo nichts mehr hereingeschrieben wird, lange überleben.

Eine Verkürzung von langen Unterverzeichnissen mit vielen gelöschten 
Einträgen erfolgt vermutlich nur bei Defragmentierung.

: Bearbeitet durch User
Autor: o ha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: michael_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter M. (r2d3)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pechvogel schrieb:
> Peter M. schrieb:
>> hast Du bei FAT32
>> Unterverzeichnisse, die eigenen Speicherplatz beanspruchen.
>
> D.h. ein Recovery-Tool kann bei FAT32 nicht sicher funktionieren?

Bei der Wiederherstellung von Dateien kann es das nicht, weil mit der 
Löschung einer Datei die zugehörigen Cluster freigegeben werden.
Damit ist nur die Information über den Startcluster übrig geblieben.
Die Folgecluster kann eine Recoverysoftware nur erraten und das geht bei 
fragmentierten Dateien schief. Das ist bei einer Löschung unter NTFS 
anders.

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

Ich freue mich. :)

Autor: Pechvogel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.