Kopiervorgang bricht ab.

[robologo2]

Hallo,

ich nutze seit Jahren Ubuntu und möchte nun auf Debian umsteigen.

Mir ist klar, dass dieses Thema schon über Jahre hinweg einige Male behandelt worden ist. Dennoch spreche ich es hier noch einmal an, weil ich weder hier noch anderswo eine Lösung gefunden habe.
Ich hatte Debian installiert. Doch nachdem ich begonnen hatte, meine noch mit Ubuntu zuvor gesicherten eigenen Dateien von der externen Festplatte in die einzelnen Verzeichnisse der Festplatte meines Rechners zu kopieren, brach Nautilus bei vielen Ordnern den Kopiervorgang ab, bzw. hängte sich auf. Ich war gezwungen, jeden einzelnen Ordner und Unterordner meiner eigenen Dateien der externen Festplatte zu öffnen, um mir die Inhalte anzeigen zu lassen. Erst danach war ein reibungsloses Kopieren möglich. In Anbetracht von knapp 20 GB eigener Dateien brach ich den Vorgang schließlich ab. Das Dateisystem der externen Festplatte von Samsung ist NTFS. Siehe: https://picasaweb.google.com/lh/photo/N ... directlink
Ich habe Debian nun zunächst wieder deinstalliert und Ubuntu zurückgespielt.
Gibt es hier im Forum bereits eine Lösung oder weiß jemand, wie das Problem zu lösen ist?

Gruß,
-Didi-

[DeletedUserReAsG]

Die einfachste Lösung wird sein, mit einem traditionellen und bewährten 'cp', oder vielleicht noch besser mit rsync zu kopieren.

cu,
niemand

[cirrussc]

Hallo und willkommen im Forum!

Ohne weitere Informationen lässt sich dazu fast nichts sagen.
Mit welcher Fehlermeldung wurde abgebrochen?
Cp oder mc in der Konsole können auch nicht kopieren?
Wie wurde gemountet? Zeichensatzproblem?
Sind die Dateisysteme clean also fehlerfrei gewesen?
Meldungen im Syslog?

[robologo2]

Der Kopiervorgang wurde mit keiner Fehlermeldung abgebrochen. Der Vorgang stoppte einfach nur. Der Fortschrittsbalken lief nicht weiter. Nautilus wurde danach teilweise unbedienbar, so dass ich den Manager per Konsole beenden musste. Cp oder mc habe ich nicht ausprobiert. Zu den restlichen Fragen kann ich leider nichts sagen. Dazu müsste ich Debian erst erneut installieren und den Vorgang wiederholen. Das Merkwürdige ist, dass dieses Problem bisher noch bei keinem Debian-Fork, sondern nur bei Debian selbst auftrat.

[Lohengrin]

Die einfachste Lösung wird sein, mit einem traditionellen und bewährten 'cp', oder vielleicht noch besser mit rsync zu kopieren.

Klickibunti ist die Pest. Das läuft für kleine Sachen ganz gut, allerdings braucht man es da auch nicht. Für das Kopieren von 20GiB rate ich dringend davon ab.

[Lohengrin]

Der Kopiervorgang wurde mit keiner Fehlermeldung abgebrochen. Der Vorgang stoppte einfach nur. Der Fortschrittsbalken lief nicht weiter.

Du könntest mit Strg+Alt+F1 auf eine Konsole wechseln, und dir mit top ansehen, was da noch läuft.

Das Merkwürdige ist, dass dieses Problem bisher noch bei keinem Debian-Fork, sondern nur bei Debian selbst auftrat.

Das wird den Debian-Entwicklern wohl kaum aufgefallen sein. Wer kopiert denn so große Datenmengen klickibunti? Das ist doch mit einem Mörderaufwand an Grafik-Firlefanz verbunden.

Ach, du bist Neuling. Willkommen im Debianforum!
Shell ist nicht böse. Gewöhn dich daran. Es gibt etwa 30 Befehle, die du fürs erste brauchst, und danach wirst du verstehen, dass das dem Klickibunti weit überlegen ist.
Hier ein Beispiel: Suche in einem Dateisystem nach Duplikaten, lösche bei mehreren alle bis auf einen und setze Links mit den Namen der anderen auf die einzig verbliebene Datei. Das kriegst du klickibunti niemals hin. Wenn das öfters vorkommt, kannst du dir für dieses Skript ein Icon auf den Desktop setzen.

[kupe]

Hier ein Beispiel: Suche in einem Dateisystem nach Duplikaten, lösche bei mehreren alle bis auf einen und setze Links mit den Namen der anderen auf die einzig verbliebene Datei. Das kriegst du Klickibunti niemals hin.

darauf würde ich wahrscheinlich nicht allzu viel wetten, enthalten doch die Ubuntu-repositories selbst hierfür auch graphische programme wie beispielsweise DupeGuru.

außerdem wird selbst unter besagtem system der zugang zu einer ordentlichen bash bei bedarf weit offen stehen, wobei ich deine kernaussage eher als freundliche aufforderung, sich mit der textuell basierten arbeiterei wenigstens rudimentär auseinanderzusetzen interpretiere. durchaus begrüßenswert...

[Lohengrin]

Hier ein Beispiel: Suche in einem Dateisystem nach Duplikaten, lösche bei mehreren alle bis auf einen und setze Links mit den Namen der anderen auf die einzig verbliebene Datei. Das kriegst du Klickibunti niemals hin.

darauf würde ich wahrscheinlich nicht allzu viel wetten, enthalten doch die Ubuntu-repositories selbst hierfür auch graphische programme wie beispeilsweise DupeGuru.

Das Programm suchen, finden, installieren und anwenden, ist mMn schon mehr als Klickibunti. Ich hatte vor ein paar Wochen mal das Problem. Da habe ich mir innerhalb von Minuten etwas zusammengedonnert. Allerdings bin ich nicht auf die Idee gekommen, das grafisch aufzumotzen und zu veröffentlichen. So etwas schreibt man sich, wenn man es braucht.

[kupe]

So etwas schreibt man sich, wenn man es braucht.

sicherlich, allerdings nur bei entsprechendem hintergrundwissen und von dessen ausprägung indirekt proportional abhängigen zeitvolumen.

und die implikation, daß diese genannten faktoren mehr oder minder hier/stets zutreffen, halte ich doch für durchaus gewagt respektive tendenziell unwahrscheinlich.

[Lohengrin]

So etwas schreibt man sich, wenn man es braucht.

sicherlich, allerdings nur bei entsprechendem hintergrundwissen und von dessen ausprägung indirekt proportional abhängigen zeitvolumen.

<klugscheießermodus>Umgekehrte Proportionalität setzt metrische Werte voraus. Hintergrundwissen ist das sicher nicht.</klugscheißermodus>

und die implikation, daß diese genannten faktoren mehr oder minder hier/stets zutreffen, halte ich doch für durchaus gewagt respektive tendenziell unwahrscheinlich.

Stimmt. Aber zum Suchen, Finden und Installieren des passenden klickibunti Programms gehört auch schon etwas. Wer das kann, kann wohl auch ein Skript schreiben.

[robologo2]

Zunächst einmal vielen Dank für die Antworten. Zur Klarstellung: Ich bin durchaus in der Lage, mit dem Terminal umzugehen. Das ist jedoch nicht der Punkt. Es ist auch nicht so, dass Debian (64-bit) nur beim Kopieren großer Datenmengen per Drag & Drop in einem Stück scheitert, sondern bereits mal nach einigen wenigen MB, dann wieder erst nach etwa 200 MB, dann jedoch läuft der Kopiervorgang plötzlich wieder in einem Stück durch. Es ist also gar kein Muster zu erkennen. Dass Debian durchaus in der Lage ist, einwandfrei selbst große Datenmengen im GB-Bereich per Drag & Drop zu kopieren, weiß ich von anderen Nutzern (die z. T. auch hier angemeldet sind). Wie bereits beschrieben, kopiert Debian Ordner einwandfrei, wenn ich diese und deren Unterordner zuvor einmal geöffnet und wieder geschlossen habe. Die Lösung dürfte daher woanders zu suchen sein.

All die Antworten sind zwar interessant zu lesen, helfen aber nicht weiter. Ich hatte gehofft, das irgendjemand ebenfalls betroffen war oder ist oder zumindest davon gelesen hat, was aber wohl nicht der Fall sein wird. Das Problem dürfte hingegen längst bekannt sein, siehe etwa
http://debianforum.de/forum/viewtopic.p ... iervorgang
oder
http://debianforum.de/forum/viewtopic.p ... iervorgang
oder
http://debianforum.de/forum/viewtopic.p ... iervorgang
Grund für meinen beabsichtigten Umstieg ist nicht nur, das Debian m. E. am besten den Open-Source-Gedanken vertritt und im Gegensatz zu Ubuntu nicht kommerziell ist. Entscheidend ist auch die fast schon legendäre Stabilität. Über Jahre stabil scheint indessen auch das hier beschriebene Problem zu sein, zumal ich noch nicht einmal einschätzen kann, ob es hardware- oder softwaretechnischer Natur ist. Sehr schade, aber wohl in absehbarer Zeit nicht zu ändern.

[Cae]

Was macht dmesg | tail -f, während du die Platte einstöpselst? Hardware ok? lspci -v zeigt bekanntermaßen kritische USB-Controller an? fsck? fdisk -l /dev/sd<Platte>?

Gruß Cae

[robologo2]

Ich hatte ja, wie oben geschrieben, Debian wieder deinstalliert und das mit Clonezilla vorab erstellte Image Ubuntus bereits wieder eingespielt, um ein funktionierendes System zur Verfügung zu haben. Daher habe ich nun die 32-bit Squeeze Live-Cd eingelegt und den Kopiervorgang gestartet. Hier kopiert Debian, ganz gleich welche Menge und welche Dateigröße, einwandfrei.

Folgende Ausgabe:
dmesg | tail -f
[ 119.856609] scsi 4:0:0:0: Direct-Access SAMSUNG HD501LJ PQ: 0 ANSI: 2 CCS
[ 119.857810] sd 4:0:0:0: Attached scsi generic sg3 type 0
[ 119.858596] sd 4:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[ 119.859092] sd 4:0:0:0: [sdb] Write Protect is off
[ 119.859097] sd 4:0:0:0: [sdb] Mode Sense: 00 38 00 00
[ 119.859100] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 119.860473] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 119.860480] sdb: sdb1
[ 119.871470] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[ 119.871478] sd 4:0:0:0: [sdb] Attached SCSI disk

[Clio]

Also nicht "Debian" an sich, sondern der jeweils eingesetzte Dateimanager ist bei der grafischen Ausführung beteiligt.
Da muß erstmal der Zwischenspeicher gefüllt werden, bevor das eigentliche Kopieren beginnt,
was u.U. lange dauert und dann auch mal abbrechen kann.
Daher ist ein Konsolenbefehl bei größeren Datenmengen immer das Mittel der Wahl, da hier ein direktes Kopieren der Daten ohne Umweg erfolgt.
Übrigens sind die Links zu alt, um aussagekräftig zu sein. Zwischen 2005 und heute liegen Welten.
@cirrussc hat es schon gesagt, da können viele Ursachen in Frage kommen, u.a. auch ein Windows-Dateisystem.

Aber Du sagst, daß Du durchaus mit einer Konsole umgehen kannst. Warum hast Du dann das System wieder gelöscht,
anstatt ein simples cp auszuführen?
Das erschließt sich mir nun überhaupt nicht, sowas machen doch gewöhnlicherweise nur Windows User....

[kupe]

interessant wäre sicherlich ebenso, inwieweit das beschriebene problem mit der verwendeten debian-version/dem verwendeten debian-zweig zusammenhängt.

unabhängig davon: hatte eigentlich das benutzte live-system haargenau den gleichen kernel/die gleiche versionsnummer wie das zuvor installierte system?
welches installationsmedium hast du denn für dein ehemalig aufgesetztes debian verwendet?

<klugscheießermodus>Umgekehrte Proportionalität setzt metrische Werte voraus. Hintergrundwissen ist das sicher nicht.</klugscheißermodus>

[oberlehrermodus]proportionalität setzt höchstens in einem einheitlichen maßsystem erfassbare werte voraus; dieses wiederum muß allerdings keineswegs das metrische/europäische sein, beispielsweise wäre das zöllige/anglo-amerikanische ebenso denkbar...[/oberlehrermodus]

[shakky4711]

Das Dateisystem der externen Festplatte von Samsung ist NTFS.

Da werden Dir jetzt x Leute sagen das läuft bei ihnen einwandfrei stabil und y Leute haben teils immense Problemen, ich gehöre zu den zweit genannten.

Mach Dir bitte bewusst dass NTFS das native Windows Dateisystem ist und alles was man darüber weiß durch Try-and-error Reverse-Engineering herausgefunden wurde. Ferner fehlen diesem Dateisystem elementare Eigenschaften die die Basis eines jeden unixartigen Betriebssystems sind, um dieses fehlenden Eigenschaften abzubilden musste wild drumherum gebastelt werden.

Ich hänge, wenn sich das partout nicht vermeiden lässt, Datenträger mit einem NTFS Dateisystem immer nur read-only ein zum Kopieren auf die Linux/BSD Systeme, wesentlich sicherer empfinde ich persönlich aber solche Platten an ein Windowssystem zu hängen und es im Netzwerk per Samba auf die Linux/BSD Maschine zu kopieren, ist auch hilfreich bei Zeichensatzproblemen. Wie gesagt, sind meine Erfahrungen und Empfehlungen, Linux mit EXT oder XFS und FreeBSD mit UFS laufen von sich her stabil wie schweizer Uhrwerke...

Wenn Du so immense Probleme hast würde ich auch mal grundsätzlich eine Dateisystemprüfung direkt mit einem Windows Rechner machen.

Gruß
Shakky

[robologo2]

Ich danke allen, die sich hier redlich bemüht haben vielmals und wünsche jenen ein angenehmes Wochenende. Was den Rest angeht, komme ich mir hier vor, wie in einem typischen Windows-Forum. Das habe ich in der Form schon seit Jahren nicht mehr erlebt. Die Angelegenheit hat sich damit für mich erledigt. Ich ziehe eine Hilfestellung durch meine Blognachbarn vor. Dennoch wünsche ich allen weiterhin viel Spaß. Chao.

[Lohengrin]

<klugscheießermodus>Umgekehrte Proportionalität setzt metrische Werte voraus. Hintergrundwissen ist das sicher nicht.</klugscheißermodus>

[oberlehrermodus]proportionalität setzt höchstens in einem einheitlichen maßsystem erfassbare werte voraus; dieses wiederum muß allerdings keineswegs das metrische/europäische sein, beispielsweise wäre das zöllige/anglo-amerikanische ebenso denkbar...[/oberlehrermodus]

Sehr schön! Hier prallen Fachsprachen aufeinander.
Ich habe an den Sprachgebrauch von Statistikern gedacht. Die unterscheiden zwischen diskreten, geordneten und metrischen Daten. Andere Mathematiker verstehen unter Metrik wieder etwas anderes. Und jetzt kommst du mit metrisch zu zöllig. Das gibt es ja auch nocht!
Worauf ich hinaus wollte: Umgekehrt proportional heißt (zumindest bei Technikern) Dreifaches rein, Drittel raus usw. Je mehr desto weniger ist eine schwächere Aussage, die allerdings dann auch bei geordneten Daten funktioniert.
Drittel Zeitintervall ist ok, aber was ist dreifaches Hintergrundwissen? Man kann jetzt versuchen, das Pferd von hinten aufzuzäumen, und das Hintergrundwissen unter Voraussetzung der umgekehrtern Proportionalität über die Zeitintervalle zu metrisieren.

Nun ja. Das ist alles Fachsprache. Möglicherweise versteht der gewöhnliche Mensch unter indirekter Proportionalität einfach nur ein (je mehr desto weniger)-Verhältnis. Dass das aber mit ausländischen Begriffen und Zeitvolumen daherkommt, hat etwas vom Spruchklopfomat.

[kupe]

Nun ja. Das ist alles Fachsprache. Möglicherweise versteht der gewöhnliche Mensch unter indirekter Proportionalität einfach nur ein (je mehr desto weniger)-Verhältnis. Dass das aber mit ausländischen Begriffen und Zeitvolumen daherkommt, hat etwas vom Spruchklopfomat.

touché, dieser absatz dürfte das aufgetretene phänomen wohl ziemlich treffend beschrieben haben, hier ein bisschen angesammeltes halbwissen, dort wieder irgendwelche fremdwörter herausgekramt und das ganze, sobald der kontext einigermaßen zu passen schien, übermutig zusammen- und durcheinandergewürfelt: fertig ist die laube.
wahrscheinlich aber fand ich den verwendeten ausdruck im vergleich zu »je weniger, desto mehr« irgendwie passender, ja geschmeidiger, und schon war's geschehen.

aber deine diesbezügliche, recht ausführliche erklärung macht (höchstwahrscheinlich zu recht) derartige wortphrasen argumentativ mehr oder weniger unbrauchbar. war auf jeden fall (obwohl offtopic) eine recht interessant zu lesende diskussion.

Was den Rest angeht, komme ich mir hier vor, wie in einem typischen Windows-Forum. Das habe ich in der Form schon seit Jahren nicht mehr erlebt. Die Angelegenheit hat sich damit für mich erledigt. Ich ziehe eine Hilfestellung durch meine Blognachbarn vor. Dennoch wünsche ich allen weiterhin viel Spaß. Chao.

auf was konkret bezieht sich denn bitteschön der hier anbelangte »rest« respektive welche sozialen und/oder fachlichen umstände rechtfertigen solcherlei vergleiche?

[Lohengrin]

Das Dateisystem der externen Festplatte von Samsung ist NTFS.

Da werden Dir jetzt x Leute sagen das läuft bei ihnen einwandfrei stabil und y Leute haben teils immense Problemen, ich gehöre zu den zweit genannten.

Ich hatte vor ein paar Tagen das Vergnügen. Ich habe hier Squeeze mit dem ganz dicken Gnome. Ein Freund gab mir eine Platte, die mit NTFS formatiert war. Ich steckte die Platte in den USB, holte mir ein paar Sachen und klickte im Gnome auf Datenträger sicher entfernen. Dann kam eine Fehlermeldung. Keine Ahnung was. Ich steckte die Platte wieder rein, brachte ein paar Dateien auf die Platte und klickte wieder auf Datenträger sicher entfernen, und bekam wieder die Fehlermeldung. Dann steckte ich die Platte wieder ein, und holte eine zuvor auf die Platte gebrachte Datei. Das funktionierte. Dann klickte ich wieder auf Datenträger sicher entfernen, und bekam wieder die Fehlermeldung.
Mein Freund versuchte dann bei sich zu Hause die Daten von der Platte zu holen. Auf Windows XP kam die Meldung, dass der Datenträger beschädigt sei. Auch mit seinem Debian Lenny konnte er die Platte nicht einbinden. Daraufhin hat er die Platte mit Windows XP wieder auf NTFS formatiert.

Keine Ahnung was das wieder war. Möglicherweise wurde die Platte auf dem Transport gestört. Die Platte ist neu, und Endkontrolle macht ja bekanntlich der Verbraucher. Ich ging bisher davon aus, dass der NTFS-Treiber problemlos zum Schreiben und Lesen taugt.

[DeletedUserReAsG]

Dann kam eine Fehlermeldung. Keine Ahnung was.

„Geht nicht“ ist ja schon bekannt, aber das ist mal neu.

cu,
niemand

[Lohengrin]

Dann kam eine Fehlermeldung. Keine Ahnung was.

„Geht nicht“ ist ja schon bekannt, aber das ist mal neu.

Du hast ja recht. Aber, weil ich trotz dieser Meldung Daten auf die Festplatte schreiben und danach wieder lesen konnte, habe ich mir diese Fehlermeldung nicht gemerkt. Dass es ein Problem gab, hat ja erst mein Freund später bei sich zu Hause festgestellt. Leider habe ich seine Festplatte mit dem NTFS nicht mehr hier. Daher kann ich die Fehlermeldung auch nicht rekonstruieren.

[cirrussc]

Das ist zwar fast OT, aber der OP ist letztendlich auch nicht mehr interessiert.

Keine Ahnung was das wieder war. Möglicherweise wurde die Platte auf dem Transport gestört. Die Platte ist neu, und Endkontrolle macht ja bekanntlich der Verbraucher. Ich ging bisher davon aus, dass der NTFS-Treiber problemlos zum Schreiben und Lesen taugt.

Ein Schaden während des Transports ist sehr unwahrscheinlich, schließlich passt das "Fehlerbild" (wenn man es so nennen möchte) nicht ganz dazu. Eventuell hat es sich darüber beschwert, dass wegen noch benutzter Dateien oder ungültiger Rechte (das kommt bei Automountern wohl vor) nicht ausgehangen werden könnte. Ob das NTFS dadurch beschädigt ist (oder dies vorgibt), kann man auch unter Linux feststellen.

[Lohengrin]

Das ist zwar fast OT, aber der OP ist letztendlich auch nicht mehr interessiert.

Keine Ahnung was das wieder war. Möglicherweise wurde die Platte auf dem Transport gestört. Die Platte ist neu, und Endkontrolle macht ja bekanntlich der Verbraucher. Ich ging bisher davon aus, dass der NTFS-Treiber problemlos zum Schreiben und Lesen taugt.

Ein Schaden während des Transports ist sehr unwahrscheinlich, schließlich passt das "Fehlerbild" (wenn man es so nennen möchte) nicht ganz dazu. Eventuell hat es sich darüber beschwert, dass wegen noch benutzter Dateien oder ungültiger Rechte (das kommt bei Automountern wohl vor) nicht ausgehangen werden könnte. Ob das NTFS dadurch beschädigt ist (oder dies vorgibt), kann man auch unter Linux feststellen.

Daran habe ich, als die Fehlermeldung kam, auch gedacht. So lautete sie aber nicht, es war nichts mehr offen, und das Icon war verschwunden. Ich wundere mich auch, dass mein Freund das Ding nicht unter Lenny mounten konnte, aber da hat ja vorher schon Windows das Ding für kaputt erklärt. Leider hat mein Freund die Platte danach mit Windows formatiert. Da ist wohl nichts mehr zu rekonstruieren.
Ich wollte nur sagen, dass ich auch zu denen gehöre, die der Kombination aus Debian und NTFS Probleme hatten.

[rhHeini]

Aus dem Thread erschliesst sich mit nicht ob der OP ntfs-3g benutzt hat oder einfach ntfs. Deswegen muss ich mal das Stichwort in die Runde werfen. Damit sollte sich auch eine NTFS-Partion einwandfrei lesen und schreiben lassen. Die Mountoption ntfs ist da problembehaftet.

Ich habe mit ntfs-3g unter Lenny gute Erfahrungn gemacht. Musst dazuinstalliert werden. Weiss nicht was Squeeze macht.

Mfg rh