Datei während der Übertragung beschädigt / verloren? Wiederherstellung möglich?

Ich war vor ein paar Tagen an der Uni, als ich versuchte, eine 500-MB-Datei (eine 3-gp-Videoaufnahme) auszuschneiden und in mein H-Laufwerk auf einem der Linux-Computer (Debian KDE 3.5) des Uni-Netzwerks einzufügen.

Ich habe keine Fehlermeldungen gesehen, die darauf hinweisen, dass das Ausschneiden und Einfügen fehlgeschlagen ist, aber wenn ich mir die resultierende eingefügte Datei anschaue, wird sie jetzt als 60-MB-Datei angezeigt (das ist eine Diskrepanz von 440 MB!). Meine Datei war irgendwie geschrumpft! Wurde die Datei beim Einfügen aufgelöst und dies ist das Fragment einer unvollständig kopierten Datei?

Ich vermute, dass die Dateiübertragung aufgrund von Einschränkungen bei der Zuweisung der Größe des H-Laufwerks unterbrochen wurde, die den Benutzern von Administratoren auferlegt wurden.

Aber Sie würden denken, Linux würde damit rechnen, dass die Datei größer ist, als es möglich wäre, zum beabsichtigten Ziel zu wechseln und die Übertragung abzubrechen, bevor sie beginnt. Warten Sie nicht, bis sie ein verbotenes Limit erreicht hat, und brechen Sie sie dann diskret ab, ohne mich zu benachrichtigen.

Auch im Falle einer unterbrochenen Dateiübertragung erwartet man normalerweise, dass die Originaldatei intakt bleibt (dh nicht gelöscht wird).

Die Datei wird im Ziel angezeigt, ist jedoch jetzt viel kleiner und funktioniert nicht mehr. Die Originaldatei im Quellspeicherort auf dem externen Laufwerk ist verschwunden, was darauf hindeutet, dass der Auftrag erfolgreich abgeschlossen wurde.

Diese Größenänderung ist ziemlich bizarr und jetzt habe ich anscheinend keinen Zugriff auf die Originaldatei. Nach dem Ausschneiden und Einfügen wurde das Original möglicherweise vom Quellspeicherort entfernt. Der Computer hat diese Aufgabe falsch gehandhabt und anscheinend meine Datei verloren. Ich möchte, dass Sie mir beim Abrufen meiner Datei helfen.

Ich habe versucht, die Datei auf der SD-Karte meines Telefons mit dem forensischen Tool PhotoRec und Sleuthkit wiederherzustellen. Kein Glück. Gelöschte Abschnitte der Festplatte wurden möglicherweise durch neue Daten überschrieben. Also kein Fortschritt am Quellende. Gibt es eine Möglichkeit, sich am Zielende (dh in meinem Uni-Netzwerk) zu erholen?

peter@peter-deb:/media/E0FD-1813$ cd DCIM/
peter@peter-deb:/media/E0FD-1813/DCIM$ cd ..
peter@peter-deb:/media/E0FD-1813$ cd LOST.DIR/
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ ls
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ ls -a
.  ..
peter@peter-deb:/media/E0FD-1813/LOST.DIR$

data-recovery

— ptrcao
quelle

Womit haben Sie die Datei kopiert / verschoben? Wie würden Sie erwarten, dass ein Kopiertool weiß, was die Systemadministratoren als maximal zulässige Dateigröße festgelegt haben? Sind Sie sich auch sicher, dass Sie keine Fingerprobleme hatten? Kein Kopiertool sollte jemals die Originaldatei löschen, wenn der Kopiervorgang noch nicht abgeschlossen ist.

— Tshepang

Das Kopiertool war Konquerer oder was auch immer der Dateimanager auf diesem KDE 3.5 Debian-Computer war. Ich bin sicher, ich habe den USB-Stecker während der Dauer des Übertragungsauftrags nicht verschoben, wenn Sie das meinen?

— Ptrcao

ptrcao, Haben Sie nach der Übertragung: (das USB-Laufwerk ausgehängt) oder (die Option zum Auswerfen / Entfernen verwendet und auf ein Popup gewartet, das besagt, dass Sie es sicher entfernen können)?

— Rozcietrzewiacz

Ja, das ist Gewohnheitssache. Der einzige Grund, warum ich das nicht tun würde, ist in einigen Netzwerken, dass die Funktion in der Desktop-Umgebung nicht aktiviert ist, aber ich erinnere mich anscheinend, dass diese Funktion im betreffenden Linux-Netzwerk verfügbar ist und von mir routinemäßig verwendet wird. Was sagt dir das? Ist etwas hilfreich?

— Ptrcao

"H-Laufwerk": Ich wette, der Täter befindet sich auf der Windows-Seite und hat nichts mit Linux, Netzwerk oder Server zu tun. Das SMB von Window scheint einige Probleme wie dieses zu haben, da es versucht, Dateien intern zu puffern und die Verknüpfung des Originals (während eines Verschiebens) vor dem Abschluss aufzuheben.

— Jonathan Cline IEEE

Antworten:

Verschieben Sie niemals eine Datei über das Netzwerk, sondern kopieren Sie sie nur. Sie können das Original jederzeit löschen, nachdem die Kopie erfolgreich abgeschlossen wurde. Zweitens ist Ihrem lokalen System möglicherweise nicht einmal bekannt, dass ein Dateisystemkontingent im Remotespeicher vorhanden ist. Gehen Sie nicht davon aus, dass es sogar möglich ist, im Voraus zu erraten, ob ein Kopiervorgang aufgrund eines Remotekontingents fehlschlagen würde. Was den "Sende" -Prozess betrifft, wurden alle Bytes an das Remote-Ende gesendet und von diesem empfangen, und Sie wollten die Datei verschieben, damit das Original gelöscht werden kann - die Poof- Datei ist verschwunden.

"Gibt es eine Möglichkeit, sich am Zielende zu erholen?" - keine Chance. OK, vielleicht eine kleine. Wenden Sie sich an den Netzwerkadministrator, um festzustellen, ob das System möglicherweise tatsächlich die vollständige Datei erhalten hat, Ihnen jedoch nur die Größe innerhalb Ihres Kontingents meldet. Halten Sie nicht den Atem an.

Und ich entschuldige mich, wenn ich ein bisschen hart klinge, aber es scheint, dass einige neue Gewohnheiten angebracht sind. :-)

— shon
quelle

Nein ... :( Wie hätte sich der Administrator nicht davor schützen können? Ich bin nur ein regulärer Schüler. Was weiß ich über Computer und Netzwerke und gute Datenverwaltungspraxis ... Sie haben einen Hoffnungsschimmer gegeben Stellen Sie eine Anfrage und öffnen Sie einen Fall, um zu sehen, ob sie meine Datei wiederherstellen können. Weitere hilfreiche, praktische Vorschläge, Dinge, die ich tun oder für mich tun lassen kann? Diese Datei war wichtig und einzigartig! Ich brauche sie. . :(

— ptrcao

Außerdem habe ich tatsächlich versucht, die Restdatei zu kopieren und zu Hause auszuführen. Tatsächlich wird es von allen Computern, die es anzeigen, als 60-MB-Datei gemeldet, und tatsächlich ist diese Datei nicht funktionsfähig. Schließt das Ihr hoffnungsvolles Szenario aus?

— Ptrcao

Haben Sie mit einem Systemadministrator gesprochen? Das ist der einzige Hoffnungsschimmer.

— Shon

Ja, keine Antwort. :( Aber sie werden irgendwann dazu kommen, nehme ich an ...

— ptrcao

Der faule Administrator wies es in einer Sekunde zurück und sagte, er wolle den Fall schließen. Es war augenblicklich. Nach all den Details, die ich in meinen Fall gesteckt habe, hat er sich nicht einmal darum

— gekümmert

Old-School-Lösung für das nächste Mal:

# sync
# sync
# sync
# umount /mnt

(Dies ist etwas sarkastisch, da die drei Synchronisierungen hintereinander alt und halb abergläubisch sind. Schauen Sie nach. Http://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync )

Es war in den SYSV-Tagen nützlich.

Ok, ich habe eine ganze Weile gebraucht, um dies auf Google zu finden. (Warum so schwer? Folklore geht verloren?) Wie auch immer, ich schlage den Youngins vor, das Unix Folklore-Buch von Raymond zu lesen (das ... ich bei Amazon nicht finden kann ...?).

http://groups.google.com/group/alt.folklore.computers/browse_thread/thread/2481588b2317173b/576619b0a9498186

— Jonathan Cline IEEE
quelle

Gibt es eine Wahrheit in der Philosophie, die Sie synchronisieren sollten? synchronisieren; synchronisieren; synchronisieren?

— Gilles 'SO - hör auf böse zu sein'

utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync

— Jonathan Cline IEEE

Heh, das bringt mich zurück. Xenix ... Synchronisieren Sie und warten Sie, bis die Festplatten-LED gedimmt ist. Wiederholen Sie dies noch zweimal und fordern Sie den Systemstopp an. Opfert noch jemand Hühner auf der Tastatur, bevor er größere Updates startet?

— Fiasko Labs