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
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.
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.
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.
Das klingt so, als würden diese bunten Markierungen von der Software ausgewürfelt ...
Pechvogel schrieb: > Eben, WinXP schreibt hier nicht auf D: Sicher? Was mit dem Index-Dienst für die Dateisuche?
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
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.
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.
Warum benutzt Du noch ein etwa 20 Jahre altes Betriebssystem mit abgelaufenem Support? Und wie immer gilt: Kein Backup, kein Mitleid.
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.
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.
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.
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.
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, 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
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.
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
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.
Angehängte Dateien:
-
Recuva.png
23 KB
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?
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
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.
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.
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.
Angehängte Dateien:
-
Recuva1.png
20 KB
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 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.
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.
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.
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.
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 ;-)
Angehängte Dateien:
-
Recuva2.png
30 KB
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.
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
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!
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. :)
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 ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.