Hallo, beim Einstecken wird mein Intenso 32GB USB-Sticks plötzlich als Wechseldatenträger angezeigt (der hatte vorher einen Namen) und beim Öffnen unter Windows muss ich lesen: "Der Datenträger ist nicht formatiert". Der Eigenschaftendialog meldet als Dateisystem RAW, 0 Byte belegt und 0 Byte frei. Recuva meldet: "Kann Dateisystem nicht ermitteln". Ubuntu erkennt den Stick erst gar nicht. LED im Stick leuchtet und blinkt. Was kann ich noch probieren, bevor ich eine Neuformatierung durchführe? Grüße von Harald
Sei froh, dass der Stick noch als Laufwerk erkannt wird. GetDataBack hat mir schon in allen dieser Situationen geholfen: https://www.runtime.org/data-recovery-software.htm
Pechvogel schrieb: > Der Eigenschaftendialog meldet als Dateisystem RAW, 0 Byte > belegt und 0 Byte frei Stick beim schreiben rausgezogen?? Evtl. findet ein Diskeditor noch ein paar Reste? Leider schwindet mit jedem Versuch mehr Hoffnung. Ontrack wenns wichtig war?
oszi40 schrieb: > Stick beim schreiben rausgezogen?? "Hardware sicher entfernen" ist doch nur für Warmduscher.
Daten von denen es keine Kopie gibt sind per Definition nicht wichtig. Neuformatieren und gut. Evtl. ist der Stecker lose (Lötstellen gebrochen) und das Teil schmiert ab jetzt immer mal wieder ab.
Ich habe mit USB-Sticks und auch SD-Karten von Intenso nur schlechte Erfahrungen. Datenverluste ohne Ende.
Hallo Pechvogel, Pechvogel schrieb: > Hallo, > > beim Einstecken wird mein Intenso 32GB USB-Sticks plötzlich als > Wechseldatenträger angezeigt (der hatte vorher einen Namen) und beim > Öffnen unter Windows muss ich lesen: "Der Datenträger ist nicht > formatiert". Der Eigenschaftendialog meldet als Dateisystem RAW, 0 Byte > belegt und 0 Byte frei. Recuva meldet: "Kann Dateisystem nicht > ermitteln". Ubuntu erkennt den Stick erst gar nicht. LED im Stick > leuchtet und blinkt. > > Was kann ich noch probieren, bevor ich eine Neuformatierung durchführe? Einen Datenabzug (Image) erzeugen, wenn's funktioniert. Neuformatierung ist gleichbedeutend mit "Pech suchen".
Jens M. schrieb: > Daten von denen es keine Kopie gibt sind per Definition nicht wichtig. Das ist genau so eine sinnfreie Argumentation wie das berühmte "Niemand zwingt dich..." als Antwort auf Kritik.
wie verhält sich ein Linux-System? Live-CD schnappen und checken.
Thomas Maier schrieb: > Das ist genau so eine sinnfreie Argumentation wie das berühmte "Niemand > zwingt dich..." als Antwort auf Kritik. Da die zuverlässigkeit von USB-Medien legendär ist, sollte man da keine Daten draufhaben die man nicht wiederbekommt. Sinnfrei ist in dem Fall der Versuch einer Wiederherstellung ohne professionelle Hilfe. Jedes Einstecken murkst eh schon an den nicht mehr vorhandenen Daten rum, und durch das Wear Leveling ist eine Datenrettung so gut wie unmöglich, wenn man den Algo nicht kennt. Ja, du kannst hunderte Dateianfänge finden, aber FAT-Reihenfolge und Flash-Reihenfolge ist nicht das gleiche. Ergo: Die Daten sind futsch, der Stick evtl. noch nutzbar wenn man ihn formatiert. Wenn die Daten wichtig waren (Doktorarbeit oder so) gehört der User gehauen wenn er die nicht woanders hat. Wenn die Daten nicht wichtig waren (es also keine Kopie gibt) ist es entweder Zeitverschwendung (etliche Programme zur Rettung finden, crack suchen, stundenlanges Deep Search bei dem dann doch nichts rauskommt) oder Geldverschwendung (5000€ für ein paar Urlaubsbilder oder so, da kannst du besser nochmal 3 Wochen Deluxeurlaub für machen). Von daher ist das nicht sinnfrei sondern einfach ein "Lern draus".
bei 0 Byte frei und 0 Byte belegt kann sich auch der Flash-Chip "verabschiedet" haben....hatte ich mal bei einem "guten" Kingston Stich :(
Jens M. schrieb: > Da die Zuverlässigkeit von USB-Medien legendär ist, hielt ich mich bis jetzt auch von SSD's fern. Nur jetzt habe ich mal ein Fund-Laptop mit ner SSD versorgt. das soll dann nur zum Surfen sein. Bin mal gespannt, wie lange das tut
Pechvogel schrieb: > Ubuntu erkennt den Stick erst gar nicht. LED im Stick leuchtet und > blinkt. Blödsinn. Verkass dich nocht auf den gui kram. Tippe "dmesg -w" ein, warte nen moment, und stecke dann den Stick ein. Schau dir dann die neuen meldungen an. Dann sieht man recht schnell, ob da noch was zu retten ist. Vermutlich ist das ding aber einfach kaputt.
Pechvogel schrieb: > Was kann ich noch probieren, bevor ich eine Neuformatierung durchführe? wird dir warscheinlich auch nix bringen, einfach putt dat Ding.. wenn es ein USB 3.0 Stick ist und ein Markenstick, dann hätte dieser wenigstens nur den Stick als read-only markiert und die Daten können noch gelesen werden.. aber die Indenso basteln doch rein was gerade da ist und wenn es aus alten Smartphones die Flashs sind.. wenn auf sowas wichtige Daten sind immer schön ein Backup machen :-)
● J-A V. schrieb: > hielt ich mich bis jetzt auch von SSD's fern. > Nur jetzt habe ich mal ein Fund-Laptop mit ner SSD versorgt. > das soll dann nur zum Surfen sein. Es ist nicht die Haltbarkeit des Flash an sich, die ist selbst bei billigen Chips sehr gut. Aber das Gestecke und Gebiege macht die Platine unzuverläsig. Ich verbaue seit Jahren nur noch SSDs, wenn ich kann Samsung Pro, angefangen bei der 840, hab aber auch schon Corsair, Toshiba und andere verbaut. Keine davon ist bislang ausgefallen. Einsatz in normalen Desktoprechnern, am RAID 5,6,10 mit 3,6 und 8 Platten, und auch in "Servern" (24/7 mit Win7 als Datei/Druckerfreigabe und CAPI-Faxserver). Eine einzige tote in einem Atom-Touchscreen hab ich, 32GB noname ohne Deckel, vollintegriert mit Adapterkabel mit Lüsterklemmen. Den hab ich aber fertig so gekauft, und der hat auch 4 Jahre gebraucht bis es geknallt hat.
oszi40 schrieb: > Stick beim schreiben rausgezogen?? Keinesfalls, das letzte Beschreiben war längst fertig, als ich den Stick abgezogen hatte. Ich sah auch keine Fehlermeldung. Stunden später wollte ich auf dem Stick was verifizieren, da war dann der Ofen aus. DPA schrieb: > Blödsinn. Verkass dich nocht auf den gui kram. Zum Glück gibt es den GUI-Kram, ohne GUI-Kram bin ich verloren ... DPA schrieb: > Tippe "dmesg -w" ein, warte nen moment, und stecke dann den Stick ein. OK, ausgeführt und vielen Dank für den Tipp ! DPA schrieb: > Schau dir dann die neuen meldungen an. Dann sieht man recht > schnell, ob da noch was zu retten ist. Ich kann schauen wie ich will, ich sehe nur Bahnhof. Kann jemand den Zeilen Informationen entlocken? Die letzte Zeile entstand nach dem Abziehen des USB-Sticks.
Nachtrag: Ich sehe 31.6GB Speicherplatz und 29.4GB belegt, also sind die Daten wohl noch da. Dann hat es sich aber schon, der Rest ist Bahnhof.
Sieht nicht nach irgendeinem Fehler aus. Davon abgesehen, daß Du immer noch nicht gelernt hast, daß man einen USB Stick nicht einfach abzieht. Windows: Hardware sicher entfernen (wurde hier schon erwähnt) Linux: Umounten Pechvogel schrieb: > Dann hat es sich aber schon, der Rest ist Bahnhof. Das solltest Du etwas näher spezifizieren wenn Du wirklich Hilfe suchst.
:
Bearbeitet durch User
Pechvogel schrieb: > Nachtrag: Ich sehe 31.6GB Speicherplatz und 29.4GB belegt, also sind die > Daten wohl noch da. Dann hat es sich aber schon, der Rest ist Bahnhof. bei sowas habe ich schon gute Erfahrungen mit dem Tool "testdisk" gemacht - hier findet sich dafür auch eine Schritt-für-Schritt-Anleitung, die sich zufällig auf einen ganz ähnlichen Fall bezieht: https://www.cgsecurity.org/wiki/Schritt_f%C3%BCr_Schritt_Wiederherstellungsbeispiel Zumindest sollte es damit recht einfach sein festzustellen, ob die Daten/Partitionen "noch da" sind... Nachtrag - könnte sein, dass einfach der "Bootsektor" des FAT32 beschädigt wurde (Datentyp "RAW" mit "0 Bytes"), das liesse sich mit dem Tool so beheben (auch aus dem Wiki zu testdisk):
1 | Der Bootsektor der logischen Fat32-Partition ist beschädigt. (Windows Fehlermeldung ist gewöhnlich Der Typ des Dateisystems ist RAW. oder Der Datenträger in Laufwerk D: ist nicht formatiert. Soll er jetzt formatiert werden?) Im Menü Advanced, wähle die Partition: |
2 | |
3 | Interface Advanced |
4 | 1 * FAT32 0 1 1 382 254 63 6152832 [LOKAL DISK] |
5 | 2 E extended LBA 383 0 1 3736 254 63 53882010 |
6 | |
7 | 5 L FAT32 383 1 1 3736 254 63 53881947 |
8 | Boot sector |
9 | test_FAT : |
10 | Partition sector doesn't have the endmark 0xAA55 |
11 | Backup boot sector |
12 | OK |
13 | First sectors (Boot code and partition information) are not identical. |
14 | Second sectors (cluster information) are not identical. |
15 | Third sectors (Second part of boot code) are not identical. |
16 | |
17 | Der Backup-Bootsektor ist gültig, wähle daher Backup BS um den Backup-Bootsektor über den Bootsektor zu kopieren. Wenn das Menü Backup BS nicht verfügbar ist, wähle RebuildBS. |
(Edit: [pre] ist hier besser als [c]. - Mod.)
:
Bearbeitet durch Moderator
Pechvogel schrieb: >> Tippe "dmesg -w" ein, warte nen moment, und stecke dann den Stick ein. > > OK, ausgeführt und vielen Dank für den Tipp ! Text kann man auch ganz ohne Bilder copy&pasten. :) > Ich kann schauen wie ich will, ich sehe nur Bahnhof. > Kann jemand den Zeilen Informationen entlocken? Zumindest kann er die Partitiontabelle lesen, denn sonst würde da nicht "sdb1" erscheinen. Ich würde an deiner Stelle erstmal einen Komplettabzug machen (als root):
1 | dd if=/dev/sdb of=/tmp/stick-kopie.dump bs=1024k |
(Aber nicht hinterher in /tmp stehen lassen, das wird beim Booten gelöscht.)
:
Bearbeitet durch Moderator
Jörg W. schrieb: > dd if=/dev/sdb of=/tmp/stick-kopie.dump bs=1024k Das wird nicht hinhauen, da meine Systempartition unter Ubuntu nur 20GB groß ist (frei sind knapp 10GB), auf dem Stick sind aber ca. 30GB. Kann aber eine externe Festplatte mit ausreichend Speicher einstecken, die wird mir auch unter "Geräte" angezeigt. Das Dateisystem der externen Festplatte ist NTFS. Wie muss man die Kommandozeile abändern?
Pechvogel schrieb: > Wie muss man die Kommandozeile abändern? So, dass der Pfadname hinter of= auf die (gemountete) externe Festplatte zeigt, also typisch irgendwo unterhalb /media/<deinusername>/<volumename>/
Pechvogel schrieb: > "Der Datenträger ist nicht > formatiert". Der Eigenschaftendialog meldet als Dateisystem RAW, 0 Byte > belegt und 0 Byte frei. Recuva meldet: "Kann Dateisystem nicht > ermitteln". Ich hatte das auch bei einer HD. Die Daten müssen nicht weg sein. Sehe mal zu, ob du die Partition in einem HD-Tool sehen kannst. Und mache eine Sicherung. Diese dann zurück auf eine HD, Stick o.ä. Wenn ich mich recht erinnere, habe ich das Dateisystem unter einem Knoppix umwandeln können.
Jörg W. schrieb: > also typisch irgendwo unterhalb > /media/<deinusername>/<volumename>/ Also "tmp" wird durch "media/<deinusername>/<volumename>" ersetzt. Der Rest dahinter bleibt trotz NTFS der Platte unverändert?
Pechvogel schrieb: > Jörg W. schrieb: >> also typisch irgendwo unterhalb >> /media/<deinusername>/<volumename>/ > > Also "tmp" wird durch "media/<deinusername>/<volumename>" ersetzt. Den führenden Schrägstrich nicht vergessen – andernfalls wäre der Pfadname relativ zum aktuellen Verzeichnis. (Ist ja nun unter Windows wirklich genauso.) > Der Rest dahinter bleibt trotz NTFS der Platte unverändert? Der Rest dahinter ist ein x-beliebiger Dateiname. Da kann alles an Zeichen drin sein außer einem Schrägstrich. OK, da es ein NTFS ist, tust du anderen Konsumentens dieses Dateisystems sicher einen Gefallen, wenn du auf besonders obskure Zeichen im Namen verzichtest, und du solltest die Datei auch nicht nul.dump, con.dump, lpt.dump oder dergleichen benennen. :-)
Hast schon mal einen anderen USB-Port bzw. anderen Rechner ausprobiert? Hat bei mir schon mal was genutzt als der Stick für nicht lesbar angezeigt wurde.
Wie erwartet nicht ganz so einfach, denn durch die 2. Festplatte liegt der Stick statt sdb nun unter sdc. Der USB-Stick blinkte nun ca. 10 min., und die HDD-LED leuchtet ab und zu kurz auf. Auf die Platte wurde aber nichts geschrieben. Das Blinken hat aufgehört und ich lese in dieser Konsole: Fehler beim Schreiben von '/media/...' und 'auf dem Gerät ist kein Speicherplatz mehr verfügbar'. Immerhin seien 10GB kopiert worden, ich finde aber nirgends eine Datei mit Namen "stick-kopie.dump" Soll in dieser einen Datei der ganze Stick gespeichert werden?
Kammando zurück, da war ein Fehler im Pfad, das hat auf die Systempartition geschrieben.
Pechvogel schrieb: > Kammando zurück, da war ein Fehler im Pfad, das hat auf die > Systempartition geschrieben. Das passt ja auch zu den 10 GB. Du kannst auch einfach vorher mit cd /media/blahblah in dein Zielverzeichnis wechseln, dann musst du bei of= nicht den ganzen langen Pfadnamen angeben, sondern nur noch den Dateinamen. (Du errätst nun sicher, dass "of=" für "output file" steht :). Aber dann nicht vergessen, danach ein "cd /" zu machen, sonst kannst du die Wechselplatte nicht wieder aushängen.
Habe diese stick-kopie.dump nun gefunden und selbige hat mir nun die Systempartition dicht gemacht. Seltsamerweise lässt sich selbige nun nicht löschen. Wie bekomme ich die Datei wieder weg?
Der 2. Versuch scheiterte wohl daran, dass die Festplatte ein Leerzeichen im Namen hatte. Aber nochmal die Frage, was fange ich mit dieser einzelnen Datei an?
dd ist für möglicherweise beschädigte datenträger nicht ideal, schon garnicht ohne conv=sync,noerror . Lieber ddrescue nehmen. Pechvogel schrieb: > Wie bekomme ich die Datei wieder weg? Gibt es eine fehlermeldung? Geht es mit "sudo rm stick-kopie.dump", nachdem du mit cd ins richtige Verzeichnis bist? Wenn du das richtige image erstellen kontest, kannst du das nochmal Kopieren, und auf der Kopie weiterarbeiten. Dann kannst du das Image mit losetup dieser als reguläres Device bereitstellen. "losetup -Pf --show stick-kopie-kopie.dump" Dann fipt es die loop devices, z.B. /dev/loop0 und /dev/loop0p1. Da kann mann dan mit mount, fsck, testdisk, etc. drauf rumexperimentieren, und im notfall wieder das alte Image kopieren, und das losetup zeug nochmal. Das losetup rückgängig machen geht mit "losetup -D /dev/loop0"
3. Versuch läuft und sieht gut aus. Die Datei stick-kopie.dump wird auf die 2. Platte geschrieben.
So, nach ca. 40 min. habe ich eine Datei mit 31.6GB erhalten. Bietet sich noch eine weitere alternative Sicherung an? Würde nämlich gerne mal das raw-usb-drive-recovery von EaseUS testen, das mir aber wohl auf dem Stick rumschreiben wird.
Falls du noch einen Stick hast, kannst du mit dd das Image auf den drauf schreiben. Dazu einfach die if und of parameter vertauschen. Aber aufpassen, dass du nicht versehentlich das falsche Gerät überschreibst.
Interressant wäre auch die Ausgabe von "fdisk -l stick-kopie.dump".
DPA schrieb: > Falls du noch einen Stick hast... Habe ich leider nicht. Deshalb auch die Frage, ob man noch andere "Abzüge" von dem beschädigten Stick machen kann. Du nanntest ddrescue.
● J-A V. schrieb: > Jens M. schrieb: >> Da die Zuverlässigkeit von USB-Medien legendär ist, > > hielt ich mich bis jetzt auch von SSD's fern. > Nur jetzt habe ich mal ein Fund-Laptop mit ner SSD versorgt. > das soll dann nur zum Surfen sein. > > Bin mal gespannt, wie lange das tut Ich hatte mal eine gekauft, die keine 2 Monate durchhielt. Bei seltener Nutzung. In meinem Laptop läuft aber jetzt schon seit Jahren eine, bei recht häufiger Nutzung.
Pechvogel schrieb: > Du nanntest ddrescue. Wenn das normale dd ohne Fehlermeldungen durchgelaufen ist, brauchst du ddrescue nicht. Das ist erforderlich, wenn sich einzelne Blöcke nicht lesen lassen, man aber trotzdem das gesamte, restliche Gerät dumpen möchte.
Ingo W. schrieb: > Wenn das normale dd ohne Fehlermeldungen durchgelaufen ist, brauchst du > ddrescue nicht. OK, auch recht ! DPA schrieb: > Interressant wäre auch die Ausgabe von "fdisk -l stick-kopie.dump". Werde ich testen, momentan läuft die Kopie der Kopie. Bei der Dateigröße dauert alles ewig :(
Pechvogel schrieb: > Nachtrag: Ich sehe 31.6GB Speicherplatz und 29.4GB belegt, Ne, wenn Du die 61747200 512 Byte Blöcke meinst 61747200 x 512 byte => 31614566400 Byte => 31,6 GB (1000er Basis) in GB auf 1024 Basis 30873600 kilo Byte 30150 mega Byte 29,443359375 Giga Byte Aus der dmesg Anzeige sieht Du nicht, wie viel belegt ist Viel Erfolg, für mich ist Intenso aber auch eine Marke, die man besser im Geschäft liegen läßt.
Bastler schrieb: > in GB auf 1024 Basis Die formal richtige Einheit währe dann aber GiB (Gigabibyte)
:
Bearbeitet durch User
DPA schrieb: > Interressant wäre auch die Ausgabe von "fdisk -l stick-kopie.dump".
1 | fdisk -l stick-kopie.dump |
2 | Medium stick-kopie.dump: 29,5 GiB, 31614566400 Bytes, 61747200 Sektoren |
3 | Einheiten: sectors von 1 * 512 = 512 Bytes |
4 | Sektorengröße (logisch/physisch): 512 Bytes / 512 Bytes |
5 | I/O Größe (minimal/optimal): 512 Bytes / 512 Bytes |
6 | Typ der Medienbezeichnung: dos |
7 | Medienkennung: 0xc9afd89b |
8 | |
9 | Gerät Boot Start Ende Sektoren Größe Id Typ |
10 | stick-kopie.dump1 2496 61747199 61744704 29,5G b W95 FAT32 |
DPA schrieb: > dd ist für möglicherweise beschädigte datenträger nicht ideal, schon > garnicht ohne conv=sync,noerror Da die Partitiontabelle offensichtlich gelesen werden konnte, hatte ich schon die Vermutung, dass es da keinerlei physische Schäden am Datenträger selbst gibt. Deshalb hatte ich conv=sync,noerror weggelassen bei meiner Empfehlung. Wenn es tatsächlich Datenträgerfehler gegeben hätte, wären andere Rettungsmethoden wohl praktikabler. Da dürfte irgendwas auf höherer Ebene zermüllt worden sein. Ist nun die Frage, wie man die Details dazu herausfindet.
DPA schrieb: > Da kann mann dan mit mount ... Haute irgendwie nicht hin: 'sudo mount /dev/loop0 /mnt' brachte folgende Antwort:
1 | mount: wrong fs type, bad option, bad superblock on /dev/loop0, |
2 | missing codepage or helper program, or other error |
3 | |
4 | In some cases useful info is found in syslog - try |
5 | dmesg | tail or so. |
Jörg W. schrieb: > Da dürfte irgendwas auf höherer Ebene zermüllt worden sein. > Ist nun die Frage, wie man die Details dazu herausfindet. Das ist genau der Punkt. Wegen meinem rudimentären Wissen werfe ich mal bis auf weiteres das Handtuch, da ich nicht wirklich weiß, was ich hier tue.
Wenn das ein 32-GB-Stick ist, weißt du denn, womit er formatiert worden ist? Bei 32 GB wäre der übliche Default eigentlich exfat. Das benimmt sich schon ein Stück anders als altes FAT (12/16/32). Ich würde ja sagen, poste hier mal den Anfang des Dateisystems (als Anhang), damit man das analysieren kann, aber ich habe gerade kein Gefühl, wieviel „Anfang“ man bei exfat tatsächlich bräuchte. Um einen Teil zu extrahieren, benutze:
1 | dd if=stick-kopie.dump of=header.dump bs=1024k count=5 |
für z.B. 5 MiB. Könntest auch erstmal mit weniger anfangen.
Pechvogel schrieb: > Haute irgendwie nicht hin: 'sudo mount /dev/loop0 /mnt' brachte folgende > Antwort: Falls du das loop device mit "losetup -Pf --show" erstellt hast, und das "loop0" ausgegeben hat, müsste es noch ein "loop0p1" erstellt haben (die -P option scant die partitionstabelle und erstellt dieses). Dieses ist die erste Partition, und das, was gemountet werden müsste. Also müsste es 'sudo mount /dev/loop0p1 /mnt' sein. Man kann auch Variationen mit "sudo mount -t exfat /dev/loop0p1 /mnt" und "sudo mount -t vfat /dev/loop0p1 /mnt" versuchen. Vorher wieder mit "dmesg -w" die Ausgabe ansehen. Das wird vermutlich nicht gehen, aber es sollte zumindest einen Anhaltspunkt geben, wo das Problem ist. Danach ist der Anfang des Dateisystems zu analysieren, wie Jörg vorgeschlagen hat, vermutlich der beste weg.
:
Bearbeitet durch User
Jörg W. schrieb: > Wenn das ein 32-GB-Stick ist, weißt du denn, womit er formatiert worden > ist? Ja, FAT32 Daniel A. schrieb: > Also müsste es 'sudo mount /dev/loop0p1 /mnt' sein. Das probiere ich morgen
Pechvogel schrieb: > DPA schrieb: >> Falls du noch einen Stick hast... > > Habe ich leider nicht. Es gibt Leute, die haben so viele davon, dass sie sie sogar verkaufen müssen...
Dreckzeug schrieb: > Ich habe mit USB-Sticks und auch SD-Karten von Intenso nur schlechte > Erfahrungen. Datenverluste ohne Ende. Bastler schrieb: > ... für mich ist Intenso aber auch eine Marke, die man besser > im Geschäft liegen läßt. Dem kann ich mich mittlerweile nur anschließen ! Bei dem Stick wurde der Steckverbinder offensichtlich manuell angelötet und man war wohl der Ansicht, dass es ausreicht, das Metallgehäuse nur einseitig anzulöten (Bild 1), und das auch nur schlampig (Bild 3). Jens M. schrieb: > Evtl. ist der Stecker lose (Lötstellen gebrochen) ... Genau so ist es. Allerdings will der Stick nach dem Nachlöten immer noch formatiert werden :( Dass Pins, die nicht verwendet werden, einfach auf den Lötstop gesetzt werden (Bild 3), sehe ich so auch zum ersten Mal. Für die Beschriftung der beiden Flash-Chips war wohl auch keine Zeit mehr. Werde künftig einen Bogen um Grabbeltische mit Ramschware machen.
Pechvogel schrieb: > Für die Beschriftung > der beiden Flash-Chips war wohl auch keine Zeit mehr. das hat einen tieferen Sinn: TTV =Tarnen Täuschen Verpissen
tastendrücker schrieb: > "Hardware sicher entfernen" ist doch nur für Warmduscher. Mal ganz nebenbei: Was passiert bei "Hardware sicher entfernen"? Wird die Betriebsspannung am betreffenden USB-Port abgeschaltet?
Die Caches werden geleert und das Gerät gesperrt damit nicht noch irgendwelche Programme Dateien offen haben.
Nachdem es mir gelang die Daten zu retten (siehe Beitrag "USB-Stick Recovery: Erfahrungen mit EaseUS Data Recovery") habe ich den Stick nun neu formatiert und dann mit h2testw vollgeschrieben. Bis dahin war alles OK (Bild 1 und 2). Dann beim Lesen/Prüfen mit h2testw die böse Überraschung: Schon beim ersten MB ging das Lesen in die Hose. Das Ding bekommt jetzt noch abschließend den 2kg Hammer zu spüren und dann ab in die Tonne mit dem Dreck.
231 Stunden um 32GB zu lesen und dann noch mit 37 kByte/s? Den Stick hat es richtig erwischt, der kann entsorgt werden.
Karl-Heinz schrieb: > Den Stick hat es richtig erwischt, der kann entsorgt werden. Sollte man meinen. Gestern noch rein interessehalber die komplette Staffel einer TV-Serie mit insgesamt 15GB auf den Stick kopiert und im TV eingesteckt. Stick wird erkannt, zwei Serien (2x 45min.) liefen einwandfrei. Also ist der Stick alles andere als defekt. Was für eine üble Technik. Freue mich schon auf die Zeit, wo solch ein Mist zwangsweise im Auto verbaut wird, Stichwort autonomes Fahren.
Karl-Heinz schrieb: > 231 Stunden um 32GB zu lesen und dann noch mit 37 kByte/s? Stresstest: schreiben (vermutlich mehrfach) und zurücklesen. Würde ich jedenfalls jetzt vermuten, dass er genau das gemacht hat. Aber wenn er natürlich so eine Fehlerrate entwickelt, dann ist es auch kein Wunder, dass das Dateisystem da drauf platt ist. Der nur mittelschlecht angelötete USB-Stecker ist dagegen ja fast nebensächlich. :)
Pechvogel schrieb: > wo solch ein Mist zwangsweise im Auto verbaut wird Warum sollte da solch ein Mist verbaut werden? Es gibt halt einen Unterschied zwischen „muss möglichst billig sein“ und „erfüllt bestimmte Qualitätsstandards“. Zumindest bislang ist die Automobiltechnik noch ganz gut dabei, das zweite durchzuziehen.
Was natürlich auch sein kann: das Ding hat gar nicht so viel Kapazität und zermüllt sich dann irgendwann, wenn man jenseits der tatsächlichen Kapazität schreibt. Solange man ihn nur allmählich füllt, fällt das nicht auf (FAT schreibt von vorn nach hinten, exFAT wahrscheinlich auch). Weiter oben stand aber, dass er ursprünglich fast voll war. Auch wenn das Testprogramm nur erst 1 MB geschrieben hatte, kann es ja gut sein, dass sie dieses 1 MB wahllos über die behauptete Kapazität versuchen zu verteilen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Pechvogel schrieb: >> wo solch ein Mist zwangsweise im Auto verbaut wird > > Warum sollte da solch ein Mist verbaut werden? > > Es gibt halt einen Unterschied zwischen „muss möglichst billig sein“ und > „erfüllt bestimmte Qualitätsstandards“. Zumindest bislang ist die > Automobiltechnik noch ganz gut dabei, das zweite durchzuziehen. wer weiss wat die sich da NOCH alles hinlügen werden. Immer dran denken, wir haben da die grössten Betrüger am Werk, die wir da in der letzten Zeit gesehen haben. Harksen, Schneider, Postel und Consorten waren dagegen nur ganz kleine Fische.
Hallo Jörg W., Jörg W. schrieb: > Karl-Heinz schrieb: >> 231 Stunden um 32GB zu lesen und dann noch mit 37 kByte/s? > > Stresstest: schreiben (vermutlich mehrfach) und zurücklesen. h2testw schreibt einfach linear weg und liest genauso einfach wieder ein.
Dreckzeug schrieb: > Ich habe mit USB-Sticks und auch SD-Karten von Intenso nur > schlechte > Erfahrungen. Datenverluste ohne Ende. Das würde ja bedeuten das du Daten in der Menge von x+1 Byte verlohren hast
Peter M. schrieb: > h2testw schreibt einfach linear weg und liest genauso einfach wieder > ein. Dafür ist die Rate allerdings dürftig (und das Testprogramm nicht gerade gut designt – IMHO).
Jörg W. schrieb: > Dafür ist die Rate allerdings dürftig (und das Testprogramm nicht gerade > gut designt – IMHO). Der Eindruck durch des Pechvogels Bild täuscht (siehe angehängtes Bild). Aus dem Bildnamen ergibt sich Dir dann der "Anschlusspfad".
:
Bearbeitet durch User
Jörg W. schrieb: > Stresstest: schreiben (vermutlich mehrfach) und zurücklesen. Hatte den Stick mit h2testw voll geschrieben, dann aber keinen Screenshot erstellt. Um das nachzuholen, bin ich gleich auf Prüfen, denn die vorher erstellten Testdateien waren ja noch auf dem Stick. Nach paar Sekunden entstand bereits die Fehlermeldung, die im Screenshot zu sehen ist. Jörg W. schrieb: > Was natürlich auch sein kann: das Ding hat gar nicht so viel Kapazität > und zermüllt sich dann irgendwann, wenn man jenseits der tatsächlichen > Kapazität schreibt. Seit ich mal mit Müll-Sticks von CN-Memory auf die Nase gefallen bin, teste ich jeden neuen Stick mehrmals mit h2testw. Der neue Stick von Intenso hatte die Tests bestanden. Jörg W. schrieb: > Es gibt halt einen Unterschied zwischen „muss möglichst billig sein“ und > „erfüllt bestimmte Qualitätsstandards“. Zumindest bislang ist die > Automobiltechnik noch ganz gut dabei, das zweite durchzuziehen. Kommt darauf an, was man als "ganz gut" definiert. Mit dem ganzen Elektronikzeugs im Auto gibt es immer mehr Probleme und nicht selten lesen auch die Spezialisten nur noch im Kaffeesatz. Am Ende wird im Unverstand getauscht. Der Kunde freut sich über horrende Rechnungen.
Jörg W. schrieb: > Es gibt halt einen Unterschied zwischen „muss möglichst billig sein“ und > „erfüllt bestimmte Qualitätsstandards“. In dem Stick sind zwei ICs verbaut, den Controller und das Flash. Beides gibt es in in einer guten und und in einer schlechten Ausführung? Falls dem so ist, wer produziert schlechte ICs und derjenige kann dafür nicht belangt werden?
Pechvogel schrieb: > Kommt darauf an, was man als "ganz gut" definiert. Dass es zumindest die Spezifikationen erfüllt. Dass natürlich ein Mehr an Komplexität auch die Ausfallwahrscheinlichkeit erhöht, ist eine andere Nummer, aber das liegt nicht unbedingt daran, dass billigster Kram produziert wird, ohne überhaupt auf Qualität zu achten. Denk einfach auch mal an Dinge wie ABS, die mittlerweile seit Jahrzehnten ganz offenbar so schlecht nun nicht ihren Dienst tun. Pechvogel schrieb: > In dem Stick sind zwei ICs verbaut, den Controller und das Flash. Beides > gibt es in in einer guten und und in einer schlechten Ausführung? Wieso das? Klar kann natürlich der Flash-Chip miserabel sein, aber es kann eben auch einfach eine schlampige (muss ja schnell fertig werden) Firmware sein, und/oder die haben ein Problem mit dem wear levelling, wenn nicht mehr ausreichend Reserveblöcke da sind – weiß der Geier™. Oder eben einfach vorsätzlichen Mist verkauft, indem mehr Kapazität behauptet wird, als tatsächlich da ist.
Jörg W. schrieb: > Klar kann natürlich der Flash-Chip miserabel sein... Interessant, für welche Anwendungen werden denn miserable Halbleiter benötigt und produziert? Und woran erkenne ich selbige? Mal eine ganz grundsätzliche Frage: Darf ein USB-Stick durch an- oder abstecken eigentlich derart defekt gehen, dass er auch nach einer Neuformatierung nicht mehr fehlerfrei arbeitet? Jörg W. schrieb: > eine schlampige (muss ja schnell fertig werden) Firmware Wie verhält sich dies dann bei meiner externen 1.5TB USB-Festplatte, kann die sich nach dem Einstecken auch mal melden mit: Ich will formatiert werden? Das wäre fatal, denn auf der Platte lagert mein gesamter Datenbestand.
Pechvogel schrieb: > Jörg W. schrieb: >> Klar kann natürlich der Flash-Chip miserabel sein... > > Interessant, für welche Anwendungen werden denn miserable Halbleiter > benötigt und produziert? Und woran erkenne ich selbige? Das ist wie mutmaßlich mit ICs bei hochwertigen Spannungsreferenz-ICs: Die besten landen in Spannungsreferenzen, die zweitbesten in Kalibratoren und die anderen in Multimetern. https://shop.heise.de/katalog/grundlagen-zu-usb-sticks Bei Sticks mit besonders hohen Schreibgeschwindigkeiten gehe ich davon aus, dass bessere Hardware drin verbaut ist. Wenn Du USB-Sticks einfach nur als Transportdatenträger und nicht als Speicherdatenträger benutzt, dann kann Dir ein Defekt nichts anhaben. :)
Pechvogel schrieb: > Interessant, für welche Anwendungen werden denn miserable Halbleiter > benötigt Bspw. für besonders billige USB-Sticks. > und produziert? Sie fallen bei der Produktion einfach so mit an. > Und woran erkenne ich selbige? Das siehst du ja gerade … > Mal eine ganz grundsätzliche Frage: Darf ein USB-Stick durch an- oder > abstecken eigentlich derart defekt gehen, dass er auch nach einer > Neuformatierung nicht mehr fehlerfrei arbeitet? Er sollte es zumindest nicht, denn USB ist hot-plug-fähig. Selbstredend kannst du dir, indem du mit deinem Betriebssystem nicht passend kommunizierst, da dateisystemmäßig einen völlig inkonsistenten Zustand einfangen, aus dem das Betriebssystem im Rahmen des vorhandenen Dateisystems keinen Ausweg mehr kennt. Aber nach Anlegen eines neuen Dateisystems muss es wieder funktionieren, sofern die Hardware generell in Ordnung ist (d.h. sie hat keine nach außen sichtbare Lese- oder Schreibfehler). > Jörg W. schrieb: >> eine schlampige (muss ja schnell fertig werden) Firmware > > Wie verhält sich dies dann bei meiner externen 1.5TB USB-Festplatte, > kann die sich nach dem Einstecken auch mal melden mit: Ich will > formatiert werden? Natürlich kann sie das, unter oben genannten Umständen. Ob und welche genauen Umstände das sind, hängt natürlich auch wesentlich vom verwendeten Dateisystem ab. Bessere Dateisysteme fassen Transaktionen so zusammen, dass sie in einem so genannten Journal aufgezeichnet werden, sodass sich immer (auch bei plötzlichem Ausfall des Übertragungswegs zum Speicher oder der Stromversorgung) ein konsistenter Zustand wieder herstellen lassen sollte. (Das muss natürlich nicht unbedingt der Zustand sein, den du erwarten würdest. ;-) https://de.wikipedia.org/wiki/Journaling-Dateisystem ext3, ext4, UFS, ZFS, NTFS gehören zu solchen Systemen. FAT oder exFAT gehören nicht dazu, sowas würde ich für eine Backup-Platte daher vermeiden.
Jörg W. schrieb: > Das muss natürlich nicht > unbedingt der Zustand sein, den du erwarten würdest. ;-) D.h. wenn es hart auf hart geht, gibt es bei den "besseren Dateisystemen" auch Ostereier? Oder was soll ich genau der Botschaft entnehmen? Auf ext3 und ext4 kann ich wohl nur aus einem Linux-System zugreifen, wenn ich das richtig verstanden habe. Also bleibt mir als Windows-Nutzer eigentlich nur NTFS.
Pechvogel schrieb: > D.h. wenn es hart auf hart geht, gibt es bei den "besseren > Dateisystemen" auch Ostereier? Oder was soll ich genau der Botschaft > entnehmen? Wenn du eine größere Datei schreibst (kann ja beim Backup mal vorkommen) und kurz danach den Stecker ziehst, dann würde beim Rollback des Journals der Zustand von zuvor, also einfach mal komplett ohne diese Datei, wiederhergestellt, falls sich der Zustand mit der Datei nicht komplett herstellen lassen konnte. Deshalb „nicht unbedingt das, was du erwartest“. Journaling garantiert nur einen in sich konsistenten Zustand. > Auf ext3 und ext4 kann ich wohl nur aus einem Linux-System zugreifen, Wahrscheinlich ja. > wenn ich das richtig verstanden habe. Also bleibt mir als Windows-Nutzer > eigentlich nur NTFS. Vermutlich die einzige Option für Windows. Die haben ja nun auch schon seit Jahrzehnten nichts mehr an ihrem Dateisystem gemacht (das hieß ja eigentlich HPFS und war ein gemeinsames Projekt zwichen Microsoft und IBM, die es in OS/2 benutzt haben).
Pechvogel schrieb: > Sollte man meinen. Gestern noch rein interessehalber die komplette > Staffel einer TV-Serie mit insgesamt 15GB auf den Stick kopiert und im > TV eingesteckt. Stick wird erkannt, zwei Serien (2x 45min.) liefen > einwandfrei. Also ist der Stick alles andere als defekt. Nachdem nun die ganze Staffel am TV ohne Probleme durchgelaufen ist, habe ich den "defekten" Stick nochmals unter Windows formatiert (kein Schnellformat) und nochmals h2testw von Anfang an durchlaufen lassen (Bild 1). Danach ein zweites mal die Daten nur gelesen und geprüft (Bild 2). Diesmal ist der Test beide Mal ohne Fehler durchgelaufen. Auch ein dritter Lesetest brachte das gleicher Ergebnis wie in Bild 2. Dies ist übrigens auch mein Standardtest bei einem neu gekauften Stick. Ein klassischer Fall von Selbstheilung, oder steht nur die Venus momentan günstig zum Pluto? Was sagen die Experten der Schlangenöl-Fraktion? Peter M. schrieb: > Wenn Du USB-Sticks einfach nur als Transportdatenträger und nicht als > Speicherdatenträger benutzt, dann kann Dir ein Defekt nichts anhaben. :) Na ja, wenn die transportierten Daten am Ziel fehlerhaft ausgelesen werden, hält sich die Freude sicher auch in engen Grenzen. Eigentlich taugt diese üble Technik nur zum Transport von Videomaterial zum nächsten TV. Da friert dann im schlimmsten Fall nur das Bild ein.
Pechvogel schrieb: > Was sagen die Experten der Schlangenöl-Fraktion? gehöre zwar nicht zu dieser fraktion, aber überall wo firmware drin ist, muss man mit allem rechnen. denn das flash ist ja offensichtlich in ordnung. schon mal mit der passenden optik die lötstellen überprüft?
Lötstelle schrieb: > denn das flash ist ja offensichtlich in ordnung Das sehe ich nicht unbedingt so. Kann gut sein, dass der Flash-Chip bereits zu viele unbrauchbare Blöcke bekommen hat. Die werden ja normalerweise durch die Firmware ausgeblendet, aber wenn keine Ersatzblöcke mehr da sind? Wer weiß, ob dieser Teil der Firmware denn je getestet worden war …
Lötstelle schrieb: > schon mal mit der passenden optik die lötstellen überprüft? Habe ich, die Lötstellen sehen zwar nicht sonderlich gut aus, alle Beine sind aber angepappt. Jörg W. schrieb: > Kann gut sein, dass der Flash-Chip > bereits zu viele unbrauchbare Blöcke bekommen hat. Die werden ja > normalerweise durch die Firmware ausgeblendet, aber wenn keine > Ersatzblöcke mehr da sind? Dann hätte h2testw nicht den ganzen Speicher vollschreiben und ohne Fehler wieder zurück lesen können. Letzteres gleich 3 mal. Allerdings: Eben ein Video mit ca. 500MB auf den Stick kopiert und bei Quelle und Ziel die Checksum (CRC32) ermittelt. Bei gleicher Dateilänge stimmt die Checksum schon mal nicht überein. Quelle: 3E801DD8, Ziel: 62D99D96. Bei einem weiteren Kopieren vom Stick auf ein anderes Medium wurde dann aus 62D99D96 -> 15C2E641 :( Scheinbar hat das Flash temporäre Ausfälle oder h2testw erkennt nicht zuverlässig ein fehlerhaftes Memory. Dachte bisher immer, dass beim Schreiben auf ein Medium irgendwie geprüft wird, ob die Daten auch fehlerfrei geschrieben wurden. Scheinbar ist dem nicht so. Man schreibt und fertig. Oder sehe ich das falsch? Gibt es ein Tool, das mir zwei Dateien auf Bitebene vergleicht und mir dann die Adressen der Unterschiede ausgibt?
Pechvogel schrieb: > Dachte bisher immer, dass beim Schreiben auf ein Medium irgendwie > geprüft wird, ob die Daten auch fehlerfrei geschrieben wurden. Beim Schreiben auf Tapes ist sowas üblich, sonst nicht. Sonst gibt's bestenfalls noch eine ECC, aber da wäre ich mir bei Flash-Speicher auch schon nicht so sicher.
Hallo Pechvogel, Pechvogel schrieb: > Ausfälle oder h2testw erkennt nicht zuverlässig ein fehlerhaftes Memory. dass h2testw nicht richtig funktioniert, halte ich für sehr unwahrscheinlich. :) Warum sagst Du nicht einfach "Speicher" statt "Memory"? > Gibt es ein Tool, das mir zwei Dateien auf Bitebene vergleicht und mir > dann die Adressen der Unterschiede ausgibt? Auf Byteebene tut das unter Windows "HxD". Mit ein wenig Arithmetik kannst Du das dann auf Deine gewünschte "Bitebene" übersetzen.
Bitte 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.