cp: reading [Dateiname] input/output error
Hallo zusammen Habe folgendes Problem: Beim Kopieren einer ca. 700 MB grossen Datei mit dem Befehl: cp [Dateiname] /tmp bekomme ich die Fehlermeldung: cp: reading [Dateiname] input/output error nach ca. 1-2 Minuten Kopiervorgang. Wie kann ich dieses Problem beheben? Speicherplatz ist auf dem Zieldatenträger (/tmp) genug vorhanden. Habe auch schon ein e2fsck des Quelldateisystems gemacht, jedoch ohne Erfolg. Ich hoffe diese Infos genügen euch und danke schon im voraus für jeden Tip Sam
* On Tue, 01 Jul 2003 at 19:37 +0200, Sam Braun wrote:
Habe folgendes Problem: Beim Kopieren einer ca. 700 MB grossen Datei mit dem Befehl:
cp [Dateiname] /tmp
bekomme ich die Fehlermeldung:
cp: reading [Dateiname] input/output error
nach ca. 1-2 Minuten Kopiervorgang.
Wie kann ich dieses Problem beheben? Speicherplatz ist auf dem Zieldatenträger (/tmp) genug vorhanden. Habe auch schon ein e2fsck des Quelldateisystems gemacht, jedoch ohne Erfolg.
Hat der Quelldatenträger einen Schaden? Was sagt der Kernel? Mach mal nach dem Kopieren dmesg und schau Dir die letzten Zeilen an. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Hallo Adalbert Danke für deine Antwort. Der Quelldatenträger ist eine 120 GB IDE Platte, welche zu ca. 95% belegt ist. Bei allen anderen Dateien habe ich bis jetzt noch nie Probleme festgestellt. Also ich denke nicht dass der Quelldatenträger einen Schaden hat. Aber ich werde den dmesg Befehl mal ausprobieren, sobald ich dazu komme... Gruss Sam
-----Ursprüngliche Nachricht----- Von: Adalbert Michelic [mailto:adalbert+list@lopez.at] Gesendet: Dienstag, 1. Juli 2003 20:00 An: suse-linux@suse.com Betreff: Re: cp: reading [Dateiname] input/output error
* On Tue, 01 Jul 2003 at 19:37 +0200, Sam Braun wrote:
Habe folgendes Problem: Beim Kopieren einer ca. 700 MB grossen Datei mit dem Befehl:
cp [Dateiname] /tmp
bekomme ich die Fehlermeldung:
cp: reading [Dateiname] input/output error
nach ca. 1-2 Minuten Kopiervorgang.
Wie kann ich dieses Problem beheben? Speicherplatz ist auf dem Zieldatenträger (/tmp) genug vorhanden. Habe auch schon ein e2fsck des Quelldateisystems gemacht, jedoch ohne Erfolg.
Hat der Quelldatenträger einen Schaden? Was sagt der Kernel? Mach mal nach dem Kopieren dmesg und schau Dir die letzten Zeilen an.
/apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hallo Adalbert Im Anhang findest du den Output vom Befehl dmesg, welchen ich gerade nach dem Fehler abgesetzt habe. Danke und Gruss Sam
-----Ursprüngliche Nachricht----- Von: Adalbert Michelic [mailto:adalbert+list@lopez.at] Gesendet: Dienstag, 1. Juli 2003 20:00 An: suse-linux@suse.com Betreff: Re: cp: reading [Dateiname] input/output error
* On Tue, 01 Jul 2003 at 19:37 +0200, Sam Braun wrote:
Habe folgendes Problem: Beim Kopieren einer ca. 700 MB grossen Datei mit dem Befehl:
cp [Dateiname] /tmp
bekomme ich die Fehlermeldung:
cp: reading [Dateiname] input/output error
nach ca. 1-2 Minuten Kopiervorgang.
Wie kann ich dieses Problem beheben? Speicherplatz ist auf dem Zieldatenträger (/tmp) genug vorhanden. Habe auch schon ein e2fsck des Quelldateisystems gemacht, jedoch ohne Erfolg.
Hat der Quelldatenträger einen Schaden? Was sagt der Kernel? Mach mal nach dem Kopieren dmesg und schau Dir die letzten Zeilen an.
/apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
* On Wed, 02 Jul 2003 at 17:14 +0200, Sam Braun wrote:
Von: Adalbert Michelic [mailto:adalbert+list@lopez.at] * On Tue, 01 Jul 2003 at 19:37 +0200, Sam Braun wrote:
Habe folgendes Problem: Beim Kopieren einer ca. 700 MB grossen Datei mit dem Befehl:
cp [Dateiname] /tmp
bekomme ich die Fehlermeldung:
cp: reading [Dateiname] input/output error
nach ca. 1-2 Minuten Kopiervorgang.
Wie kann ich dieses Problem beheben? Speicherplatz ist auf dem Zieldatenträger (/tmp) genug vorhanden. Habe auch schon ein e2fsck des Quelldateisystems gemacht, jedoch ohne Erfolg.
Hat der Quelldatenträger einen Schaden? Was sagt der Kernel? Mach mal nach dem Kopieren dmesg und schau Dir die letzten Zeilen an.
Im Anhang findest du den Output vom Befehl dmesg, welchen ich gerade nach dem Fehler abgesetzt habe.
[...]
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=133520985, sector=133520920 end_request: I/O error, dev 16:01 (hdc), sector 133520920
Sorry, tut mir leid - aber die Platte hat ziemlich sicher was. Wenn das nochdazu eine so riesige IDE-Platte ist, wie Du in der anderen Mail geschrieben hast, dann ists noch wahrscheinlicher. Wenn Du Glück hast, hats nur was am Kabel, aber das glaub ich nicht. Die dicken IDE-Platten sterben alle der Reihe nach wie die Fliegen[1]. Zieh die wichtigen Daten ab, versuch den Rest zu retten und schick dann die Platte ein. [1] Bis IBM kleiner DTLA war die Welt noch in Ordnung, dann hats angefangen. IBM hats vorgemacht, alle habens nachgemacht. So ziemlich alle Platten, die in meiner Reichweite herumlaufen, und die so hohe Datendichten haben, haben einen Schaden. Mag sein, daß Hitze das begünstigt, aber die kalten erwischts genauso. Dauert blos u.U. länger. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Hallo Adalbert Komisch, das ist jetzt die erste Datei bei der so was auftritt. Gibt es da nicht irgend ein Test Tool wo man das Prüfen kann ob die Platte kaputt ist? Das Kabel denke ich auch nicht dass es das ist, da sonst bei anderen Dateien dieser Fehler auch auftreten würde. Danke und Gruss Sam
-----Ursprüngliche Nachricht----- Von: Adalbert Michelic [mailto:adalbert+list@lopez.at] Gesendet: Mittwoch, 2. Juli 2003 17:21 An: suse-linux@suse.com Betreff: Re: cp: reading [Dateiname] input/output error
* On Wed, 02 Jul 2003 at 17:14 +0200, Sam Braun wrote:
Von: Adalbert Michelic [mailto:adalbert+list@lopez.at] * On Tue, 01 Jul 2003 at 19:37 +0200, Sam Braun wrote:
Habe folgendes Problem: Beim Kopieren einer ca. 700 MB grossen Datei mit dem Befehl:
cp [Dateiname] /tmp
bekomme ich die Fehlermeldung:
cp: reading [Dateiname] input/output error
nach ca. 1-2 Minuten Kopiervorgang.
Wie kann ich dieses Problem beheben? Speicherplatz ist auf dem Zieldatenträger (/tmp) genug vorhanden. Habe auch schon ein e2fsck des Quelldateisystems gemacht, jedoch ohne Erfolg.
Hat der Quelldatenträger einen Schaden? Was sagt der Kernel? Mach mal nach dem Kopieren dmesg und schau Dir die letzten Zeilen an.
Im Anhang findest du den Output vom Befehl dmesg, welchen ich gerade nach dem Fehler abgesetzt habe.
[...]
hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x40 { UncorrectableError }, LBAsect=133520985, sector=133520920 end_request: I/O error, dev 16:01 (hdc), sector 133520920
Sorry, tut mir leid - aber die Platte hat ziemlich sicher was. Wenn das nochdazu eine so riesige IDE-Platte ist, wie Du in der anderen Mail geschrieben hast, dann ists noch wahrscheinlicher. Wenn Du Glück hast, hats nur was am Kabel, aber das glaub ich nicht. Die dicken IDE-Platten sterben alle der Reihe nach wie die Fliegen[1].
Zieh die wichtigen Daten ab, versuch den Rest zu retten und schick dann die Platte ein.
[1] Bis IBM kleiner DTLA war die Welt noch in Ordnung, dann hats angefangen. IBM hats vorgemacht, alle habens nachgemacht. So ziemlich alle Platten, die in meiner Reichweite herumlaufen, und die so hohe Datendichten haben, haben einen Schaden. Mag sein, daß Hitze das begünstigt, aber die kalten erwischts genauso. Dauert blos u.U. länger.
/apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
* On Wed, 02 Jul 2003 at 17:36 +0200, Sam Braun wrote:
Komisch, das ist jetzt die erste Datei bei der so was auftritt.
So fängts immer an. Aber bei 120 GB wirst Du ja eine Weile brauchen, um das alles durchzugehen, oder?
Gibt es da nicht irgend ein Test Tool wo man das Prüfen kann ob die Platte kaputt ist?
Ja. badblocks /dev/hdc.
Das Kabel denke ich auch nicht dass es das ist, da sonst bei anderen Dateien dieser Fehler auch auftreten würde.
Ja, denke ich auch. Es wär nur ein Hoffnungsschimmer :-) /apm, gerade dabei eine 4 Monate alte 80GB Maxtor-Platte gegen zwei gespiegelte 160er zu tasuchen. Mir reichts jetzt, den Luxus auch zuhause RAID1 zu haben, gönne ich mir. -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Sam Braun schrieb:
Gibt es da nicht irgend ein Test Tool wo man das Prüfen kann ob die Platte kaputt ist?
Bei IBM (bzw. inzwischen Hitachi) heisst so ein Fest- plattentool DFT (=Drive Fitness Test). Das prueft die Festplatte auf Herz und Nieren. Andere Hersteller duerften aehnliche Werkzeuge haben. Unter Linux selbst kannst Du es vielleicht mal mit badblocks probieren.
[...TOFU entsorgt...]
Bitte lerne, Emails ordentlich zu zitieren! Du findest hierzu Informationen unter http://learn.to/quote/. Gruesse, Thomson
* On Wed, 02 Jul 2003 at 17:50 +0200, Andreas Feile wrote:
Adalbert Michelic, Mittwoch, 2. Juli 2003 17:42:
Ja. badblocks /dev/hdc.
Mit badblocks kann ich aber nicht die Oberfläche der HD testen oder? Mit welcher Software kann man das tun?
Was meinst Du mit Oberfläche? badblocks liest die Platte blockweise durch. Wenn wo ein Fehler kommt, wird der gemeldet. Wenn ein Fehler kommt, und der wirklich von der Platte kommt, und nicht anderweitig bedingt ist, so ist das bei halbwegs modernen Platten ein sicheres Zeichen dafür, daß sie bald gaga ist. Wenn sich nicht mal mehr die Platte selbst helfen kann, dann kann es ein Normalsterblicher schon gar nicht. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Ja aber die Platte ist zu 98% belegt. Ok, ich habe nicht alle Dateien auf Lesbarkeit getestet, aber im letzten Jahr habe ich bis jetzt mit keiner Datei Probleme gehabt. Oder meinst du dass dies jetzt nachträglich sich eingeschlichen hat? Ich mache jetzt auf jeden Fall mal den Badblocks... Danke und Gruss Sam
-----Ursprüngliche Nachricht----- Von: Adalbert Michelic [mailto:adalbert+list@lopez.at] Gesendet: Mittwoch, 2. Juli 2003 17:43 An: suse-linux@suse.com Betreff: Re: cp: reading [Dateiname] input/output error
* On Wed, 02 Jul 2003 at 17:36 +0200, Sam Braun wrote:
Komisch, das ist jetzt die erste Datei bei der so was auftritt.
So fängts immer an. Aber bei 120 GB wirst Du ja eine Weile brauchen, um das alles durchzugehen, oder?
Gibt es da nicht irgend ein Test Tool wo man das Prüfen kann ob die Platte kaputt ist?
Ja. badblocks /dev/hdc.
Das Kabel denke ich auch nicht dass es das ist, da sonst bei anderen Dateien dieser Fehler auch auftreten würde.
Ja, denke ich auch. Es wär nur ein Hoffnungsschimmer :-)
/apm, gerade dabei eine 4 Monate alte 80GB Maxtor-Platte gegen zwei gespiegelte 160er zu tasuchen. Mir reichts jetzt, den Luxus auch zuhause RAID1 zu haben, gönne ich mir. -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
* On Wed, 02 Jul 2003 at 18:02 +0200, Sam Braun wrote:
Ja aber die Platte ist zu 98% belegt.
Dann ist sie eh schon zu voll. 80%, max 90% - mehr solltest Du dem Filesystem nicht zumuten, wenn Du noch halbwegse Performance möchtest.
Ok, ich habe nicht alle Dateien auf Lesbarkeit getestet, aber im letzten Jahr habe ich bis jetzt mit keiner Datei Probleme gehabt. Oder meinst du dass dies jetzt nachträglich sich eingeschlichen hat?
Ja, das kommt. Irgendwann dejustiert sich der Kopf oder weiß Gott was, und dann die Platte der Reihe nach immer mehr Bereiche nicht lesen. Das Zeug geht je nicht unbedingt vom Zugriff kaputt, da fällts es auf, daß es mal kaputtgegangen ist.
Ich mache jetzt auf jeden Fall mal den Badblocks...
Ahja, während Du badblocks zuschaust, führ Dir mal bitte http//learn.to/quote/ zu Gemüte. Muchas gracias. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Adalbert Michelic, Mittwoch, 2. Juli 2003 17:58:
Was meinst Du mit Oberfläche? badblocks liest die Platte blockweise durch.
Jo, lesen - aber wie kann man einen Schreib-/Lesetest durchführen? Wäre es nicht denkbar, daß eine Stelle zwar noch lesbar, aber nicht mehr beschreibbar ist? -- Andreas Feile www.feile.net
* On Wed, 02 Jul 2003 at 18:56 +0200, Andreas Feile wrote:
Adalbert Michelic, Mittwoch, 2. Juli 2003 17:58:
Was meinst Du mit Oberfläche? badblocks liest die Platte blockweise durch.
Jo, lesen - aber wie kann man einen Schreib-/Lesetest durchführen? Wäre es nicht denkbar, daß eine Stelle zwar noch lesbar, aber nicht mehr beschreibbar ist?
Eher genau das Gegenteil. Beim Schreiben reloziert die Platte die defkte Stelle und Du kriegst es nicht mal mit. Scheibtests würde ich mir bei Platten, die ich wem nachschmeissen will, tunlichst verkneifen. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Hallo zusammen
Ich mache jetzt auf jeden Fall mal den Badblocks... Nun nach ca. 48h badblocks bekam ich folgendes Ergebnis: 40 kaputte Blöcke von ca. 1,2 Millionen. (66760456 - 66760495). Kann man das Dateisystem nicht irgendwie dazu bringen diese Blöcke einfach nicht mehr zu beschreiben? (So ähnlich wie das Scandisk von Microsoft :-))
Danke und Gruss Samuel
* On Sat, 05 Jul 2003 at 12:05 +0200, Sam Braun wrote:
Ich mache jetzt auf jeden Fall mal den Badblocks... Nun nach ca. 48h badblocks bekam ich folgendes Ergebnis: 40 kaputte Blöcke von ca. 1,2 Millionen. (66760456 - 66760495). Kann man das Dateisystem nicht irgendwie dazu bringen diese Blöcke einfach nicht mehr zu beschreiben? (So ähnlich wie das Scandisk von Microsoft :-))
Zumindest ext2 kann das (siehe manpage von badblocks). Vermutlich kannst Du sie auch wieder zum Leben erwecken, indem Du einfach was drüberschreibst. Aber an dieser Stelle sei eine Warnung angebracht: Bei diesen 40 Blöcken bleibts nicht. Garantiert. Die Platte geht über kurz oder lang ein. Wenn Du sie trotzdem verwenden willst, lasse nichts wichtiges drauf. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Hallo, On Sat, 05 Jul 2003, Sam Braun schrieb:
Ich mache jetzt auf jeden Fall mal den Badblocks... Nun nach ca. 48h badblocks bekam ich folgendes Ergebnis: 40 kaputte Blöcke von ca. 1,2 Millionen. (66760456 - 66760495). Kann man das Dateisystem nicht irgendwie dazu bringen diese Blöcke einfach nicht mehr zu beschreiben? (So ähnlich wie das Scandisk von Microsoft :-))
Bei ext2/3 und minix (AFAIR) kann man z.B. -c oder die von badblocks erzeugte Ausgabe verwenden um eine "dummy-Datei" (.badblocks) anzulegen, die diese Bloecke "belegt". Aber wenn du auf einer Festplatte auf defekte Bloecke stoesst, kannst du davon ausgehen, dass es die Festplatte nicht mehr lange macht. -dnh -- 271: Usenet Eine Diktatur von Newsserverbetreiber, die größtenteils auf das nörgelnde Volk hört (so es sich denn einig ist). (Cornell Binder)
Kann man das Dateisystem nicht irgendwie dazu bringen diese Blöcke einfach nicht mehr zu beschreiben? (So ähnlich wie das Scandisk von Microsoft :-))
Zumindest ext2 kann das (siehe manpage von badblocks). Habe jetzt die Option gefunden: e2fsck /dev/hdc1 -l [Listenfile von badblocks]. Muss es einmal ausprobieren...
Vermutlich kannst Du sie auch wieder zum Leben erwecken, indem Du einfach was drüberschreibst. Wie kann ich das machen? Genau auf die gewünschten Blöcke was draufschreiben?
Aber an dieser Stelle sei eine Warnung angebracht: Bei diesen 40 Blöcken bleibts nicht. Garantiert. Die Platte geht über kurz oder lang ein. Wenn Du sie trotzdem verwenden willst, lasse nichts wichtiges drauf. Ja das ist mir schon klar, eine Festplatte funktioniert ja nicht ewig. Vor allem wenn sie fast ununterbrochen läuft.
Danke und Gruss Samuel
* On Sat, 05 Jul 2003 at 12:50 +0200, Sam Braun wrote:
Vermutlich kannst Du sie auch wieder zum Leben erwecken, indem Du einfach was drüberschreibst. Wie kann ich das machen? Genau auf die gewünschten Blöcke was draufschreiben?
Ja. Mit 'dd if=/dev/zero of=/dev/xxx bs=zzz count=1 seek=yyy' kannst Du das machen, xxx ist das Device, yyy ist der Offset des Sektors relativ zum Plattenanfang, zzz die Blockgröße. Pass aber höllisch auf, wenn Du den Offset errechnest; Die Blocknummer kriegst Du ja von badblocks, für zzz kommt die Blockgröße, die auch badblocks verwendet hat. Aber Vorsicht - ich weiß nicht, ob die Blocknummern bei badblocks nullbasiert oder einsbasiert sind. Teste vor dem Überschreiben: 'dd if=/dev/xxx of=/dev/null bs=zzz count=1 skip=yyy'. Wenn da kein Fehler kommt, sitzt Du auf dem flaschne Block.
Aber an dieser Stelle sei eine Warnung angebracht: Bei diesen 40 Blöcken bleibts nicht. Garantiert. Die Platte geht über kurz oder lang ein. Wenn Du sie trotzdem verwenden willst, lasse nichts wichtiges drauf. Ja das ist mir schon klar, eine Festplatte funktioniert ja nicht ewig. Vor allem wenn sie fast ununterbrochen läuft.
Ununterbrochen laufen tut den Platten nicht so viel. Es ist nur leider so, daß scheinbar die Datendichte, die die Platten haben, weit schneller gestiegen ist, als das Know-How der Hersteller. Schön langsam wirds wieder besser, aber da gabs mal eine Zeit, da starben die Platten wie die Fliegen. Eine Platte hat normalerweise immer fehlerhafte Stellen. Aus diesem Grund hat eine Platte immer mehr Kapazität, als angegeben. Die Platte ist nun so schlau, zu bemerken, wenn ein Bereich kaputtzugehen droht, und verschiebt diesen Bereich dann in den noch ungenutzten Pufferbereich. Das kriegst Du normal gar nicht mit. Soweit alles gut. Wenn nach aussen hin defekte Stellen sichtbar werden, ist der Pufferbereich vermutlich schon voll, und dementsprechend eine ganze Menge kaputt. Die Platte weiß sich dann nicht mehr zu helfen. Das sind genau die Symptome, wie ich sie bis jetzt noch bei so ziemlich jeder Platte aus einer der "grossen" Serien (also die, mit der hohen Datendichte) beobachtet habe. Das fängt mal harmlos an, und wenn man dann nicht schnell reagiert, ist es aus. Bei meiner ersten, die so reagiert hat, habe ich auch noch gedacht, was solls - den Bereich blende ich einfach aus. Ging dann wieder super. 4 Wochen später, und ich habe die Angelegenheit verdrängt, keine neuen fehlerhaften Stellen mehr. 5 Wochen später, und die Platte gab genau _keinen_ Mucks mehr von sich. Njente. /apm -- GPG welcome, request public key: mailto:adalbert+key@lopez.at
Ja. Mit 'dd if=/dev/zero of=/dev/xxx bs=zzz count=1 seek=yyy' kannst Du das machen, xxx ist das Device, yyy ist der Offset des Sektors relativ zum Plattenanfang, zzz die Blockgröße. Pass aber höllisch auf, wenn Du den Offset errechnest; Die Blocknummer kriegst Du ja von badblocks, für zzz kommt die Blockgröße, die auch badblocks verwendet hat. Aber Vorsicht - ich weiß nicht, ob die Blocknummern bei badblocks nullbasiert oder einsbasiert sind.
Teste vor dem Überschreiben: 'dd if=/dev/xxx of=/dev/null bs=zzz count=1 skip=yyy'. Wenn da kein Fehler kommt, sitzt Du auf dem flaschne Block. Tönt nicht gerade sehr einfach...
Nun ich habe vorher versucht die kaputten Blöcke mit dem Befehl: e2fsck /dev/hdc1 -l [Liste mit kaputten Blocks] -v auszublenden. E2fsck gibt jedoch nun an, dass die Blöcke ausserhalb des zulässigen Bereich sind. Ich denke hier habe ich noch eine Problem. Wo kann ich dann die Blockgrösse, Anzahl Sektoren, etc. nachschauen? Danke und Gruss Sam
Hallo David
Bei ext2/3 und minix (AFAIR) kann man z.B. -c oder die von badblocks erzeugte Ausgabe verwenden um eine "dummy-Datei" (.badblocks) anzulegen, die diese Bloecke "belegt".
Diese Liste von Badblocks habe ich schon, jedoch funktioniert dies nicht so ganz. (Siehe vorheriges Mail von mir). Und ich habe nicht so Lust die ganze Festplatte nochmals abzuscannen, da es ca. 48h geht. Danke und Gruss Sam
participants (5)
-
Adalbert Michelic -
Andreas Feile -
David Haller -
Sam Braun -
Thomas Hertweck