Datei Teilkopien - wie abschalten?

Datei Teilkopien - wie abschalten? (14 Beiträge, 733 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Mein System: Linux Mint 18.1 Serena mit Cinnamon.

Ich habe gerade ein Heimvideo auf meine WD-Netzwerkfestplatte kopiert.

Da es offensichtlich urlangsam ist, etwas über Samba zu kopieren (keine 10 Mbit/s im Vergleich zu 112 Mbit/s unter Windows 10), habe ich abgebrochen.

Was mich nun schockiert hat, ist, dass die Datei am Zielort existent war, jedoch nur partiell. Ich kann die Datei also aufmachen, ansehen, aber nur so weit, wie sie kopiert worden ist.

Das ist natürlich ein riesiges Datensicherheitsproblem, besonders dann, wenn auch Menschen am Computer arbeiten, die sich dieser Gefahr nicht bewusst sind.

Meine Fragen nun:

a) Betrifft das nur Videodateien?
b) Betrifft das nur den Dateimanager? (Nemo 3.2.2)
c) Wie kann ich bewirken, dass eine Datei (so wie in Windows) automatisch gelöscht wird, wenn sie nicht vollständig kopiert wurde?

a) nein
b) wahrscheinlich nicht nur den = manche Programme kriegen einen Abbruch mit (durch Benutzer oder aber durch andere Einflüsse), andere nicht
c) midnight commander (mc) ... ist relativ gut geeignet, um gezielt zu kopieren/verschieben/abgleichen (ebenso wie total commander unter Windows auch um Klassen besser ist, als die Standardfilemanager).
Das Dilemma liegt aber schon beim Verhalten des Netzwerkfilesystems an sich = wie geht der Fileserver mit einem Abbruch um? Manche Programme benennen während des Kopierens die Zieldatei noch als ".part" o.ä. und erst bei Erfolg werden Name + Timestamps der Quelle angeglichen.

und ja: die Semantic beim Kopieren von Daten ist ein Trauerspiel, wie zu DOS-Zeiten. Was im Grunde fehlt, ist ein tiefer angesiedelter Mechanismus, um 2 Verzeichnisse bzgl. Abgleich (sync in eine oder beide Richtungen) intuitiv zu verknüpfen, also quasi rsync-Parameter pro Verzeichnis/Zweig mit einem deppensicheren Frontend für die gängigsten paar Fälle + bereits im Filesystem verankerten Verhalten, das auf Diskrepanzen hinweist.

Danke! Jetzt wird mir einiges klarer.

Es ist ja in Windows auch noch nicht perfekt. Ich frage mich immer, warum beim Kopieren von vielen Verzeichnissen mit Inhalt gleich komplett abgebrochen wird, wenn der Zieldatenträger voll ist oder einfach eine Datei aus irgendeinem Grund nicht kopierbar ist. Auch Microsoft ist noch nicht auf die Idee gekommen, hier einfach mal 'ne Pause machen zu lassen, bis der Benutzer interagiert und das Problem löst, indem er beispielsweise einfach eine geöffnete Datei schließt oder ein wenig Platz freischaufelt.

Aber nein, lieber packt man in neue Versionen unendlich viele Gimmicks für den DAU, als einfach mal die Basics zu überarbeiten.

hab meinem obigen Sermon wenig hinzuzufügen und mache aus meiner Verachtung für Windows wenig Hehl

Das Verhalten des FileExplorer hat sich über die Version (also Win 7 aufwärts) schon verbessert, aber gleichzeitig sind halt andere Annoyances dazugekommen.

Total Commander ist halt immer noch das Tool der Wahl bzgl Massendateiverwaltung.
Wer es etwas mehr Richtung Drag&Drop mag ... Tools wie Teracopy ansehen.

Am Mac ist das out-of-the-box Verhalten besser bzw. zumindest gut genug, nicht STÄNDIG mit mc im Terminal zu arbeiten.

Unter Linux ... bin eigentlich in > 20 Jahren mit keinem Desktop dauerhaft warm geworden (windowmaker ist wenigstens sauschnell + genügsam), egal ob nautilus oder sonstigen GNOME/KDE-eigenen Filemanagern, oder sonstigen GUI-MC-Klonen (was nicht heißt, daß nicht der eine oder andere wie fileroller ganz OK sind), wirklich gern gearbeitet hab ich nur mit tkdesk (das den ursprünglichen NeXTstep-Filemanager und Mac-Finder-Vorgänger grob nachahmt, aber deutlich toppt) - dessen Feinschliff+Konfiguration sind halt eine eigene Sache. Leider hat tkdesk seit Jahren keinen Maintainer mehr.

Am Mac ist das out-of-the-box Verhalten besser bzw. zumindest gut genug, nicht
STÄNDIG mit mc im Terminal zu arbeiten.

http://www.mucommander.com/

kenn ich .. im Grunde einer der besseren + plattformübergreifenden Vertreter, aber halt um den Preis von Java-Feeling + üblichen Haken und Ösen am Mac = Integration und seamless Feeling bescheiden.

Aber nein, lieber packt man in neue Versionen unendlich viele Gimmicks für den
DAU, als einfach mal die Basics zu überarbeiten.

Weil's dafür rsync gibt.

Aber ich weiß, für Leute die nur 'n Hammer kennen schaut jedes Problem wie 'n Nagel aus...

________________________________________________________________________

There's a typo in the Bible. It should read "The geek shall inherit the earth".

Weil's dafür rsync
gibt.

natürlich ist rsync immer eine tolle Antwort, aber für einmalige bzw sporadische Kopieraktionen einen Enduser auf die Commandline schicken und mit dessen Syntax (angefangen beim leidigen, uralten "/" vs. "\\" Problem, weil Billy damals unbedingt was anders machen wollte...) zu behelligen, trifft es auch nicht.
Klar gibt es ein allerlei rsync-Frontends auf sämtlichen Plattformen, aber ein wirklich überzeugendes hab ich auch noch nicht gefunden.

Aber ich weiß, für Leute die nur 'n Hammer kennen schaut jedes Problem wie 'n
Nagel aus...

den Spruch bring ich auch gern, da muß ich - bei aller Affinität zu Linux+BSD aber auch sagen: die Usability ist sowohl am Desktop als auch auf der Commandline vor Jahren steckengeblieben = eine gewisse Betriebsblindheit und Arroganz gegenüber Einsteigern und Noobs ist geblieben = nur wenige Unixer haben so engen "Feindkontakt" + Objektivität, daß sie die fraglosen Unzulänglichkeiten der User Experience wirklich reflektieren.
Sich drauf rauszureden, daß Desktop A und Tool B und Workaround C ach so toll sind, hilft nicht. Die Konzepte in der Basisausstattung sind schon praktisch überall unzureichend für heutige Anforderungen.

Da kann ich Dir nun wieder nicht weiterhelfen, abseits der Kommandozeile bin ich in Linux genauso verloren wie jeder andere, der XWindow verwendet.

________________________________________________________________________

There's a typo in the Bible. It should read "The geek shall inherit the earth".

Da kann ich Dir nun wieder nicht weiterhelfen, abseits der Kommandozeile bin
ich in Linux genauso verloren wie jeder andere, der XWindow verwendet.

kann mich noch lebhaft erinnern, wie ich vor 20 Jahren jemand beobachtet hab, der vor einer SGI Indy mit zugehörigem Monitor (Trinitron, weiß nicht mehr ob 17 oder damals unfaßbar teure 20") gesessen ist und das feine Teil eigentlich nur dazu gebraucht hat, um 4 große Terminalfenster nebeneinander zu haben .... heute isses oft nicht anders, nur daß stattdessen Win7 aufwärts + Putty + >=22" zum Einsatz kommen ----> insofern würd ich schon behaupten, daß da eine Gilde ziemlich versagt bzw. die Puristen eine echte Weiterentwicklung verwunderlichste verhindert hat.

Auf der anderen - positiveren - Seite rollen Appliances und Apps das Thema Frontends und GUIs unauffällig per HTML5 auf, aber halt immer spezifisch (zB diverse NAS, Router, Drucker oder Appliance-Distributionen mit entsprechender Funktion + immer mehr Zusatzfeatures). Aber halt eingeschränkt + optimiert auf das jeweilige Produkt. Ein Quantensprung wäre es, die bisherige Unix-Dualität der Programme von Text/Dialog + X auf breiter Basus um eine REST-Ebene bzw. einer gemeinsamen Protokollabstraktion zu erweitern, umso mehr, als X eh irgendwie auf der Abschußliste steht, zw. Wayland, proprietären Framebuffer-Frameworks (alle embedded Systeme inkl. Android), VNC-Kronprinzen (Spice, RDP, NX etc.)
Ein grundlegendes Umdenken ist überfällig.

Aber gut ... wir/ich entferne mich vom Thema.

Auch Microsoft ist noch nicht auf die Idee gekommen, hier einfach mal 'ne
Pause machen zu lassen, bis der Benutzer interagiert und das Problem löst,
indem er beispielsweise einfach eine geöffnete Datei schließt oder ein wenig
Platz freischaufelt.

Macht Windows bei den Serverversionen schon länger, und bei den Consumerversionen imho seit Win 10 (8 hatte ich nicht)

Da es offensichtlich urlangsam ist, etwas über Samba zu kopieren (keine 10
Mbit/s im Vergleich zu 112 Mbit/s unter Windows 10), habe ich abgebrochen.

Das würde mir eher Sorgen machen...ich kann von meinem Windows-PC über SMB/Samba mit über 100MB/s auf eine Festplatte kopieren, die per USB an meinem Linux-Server angeschlossen ist.

25.02.2017, 02:18 Uhr - Editiert von mko, alte Version: hier

den Part hab ich vorhin nur überflogen ...
naja, der übliche Vorgang: Flood-Ping testen oder schon auf Ethernet-Ebene was hakt, dann mit den cifs-Meldungen im dmesg sichten um Protokollproblemen auf die Spur zu kommen.
bzw. erst einmal schauen, ob die SMB/CIFS-Verbindung von Mint/Gnome/gtkvfs aufgebaut wird oder als echter mount.

Dieser Beitrag bezieht sich auf eine ältere Version des beantworteten Postings!

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung