Hallo Leute,
ich wollte eine Menge Dateien (aber eben nicht alle) in einen Ordner
namens tmp kopieren und habe dafür dieses Skript auf den Perlinterpreter
losgelassen:
1
for($i=96;$i<301;$i+=2)
2
{
3
$v=sprintf("move scan%03d.jpg /tmp\n",$i);
4
system($v);
5
}
Das hätte ich vorher besser mal testen sollen, die Dateien sind nämlich
komplett verschwunden. Der Ordner tmp ist leer.
Kennt jemand einen Trick um meine Daten wieder aus dem binären Nirvana
zu zaubern? Windowssuche und ein Recoverytool waren erfolglos, ebenso
der verzweifelte Versuch "move /tmp/scan*.jpg C:\"...
Und nein es gibt keine Sicherung davon und ja das ist nicht gut...
Vollidiot... schrieb:> Dann hätte die Windowssuche sie doch finden müssen?!
Nicht zwingend, die durchsucht ja nicht unbedingt das Dateisystem,
sondern nur irgendeinen Index, und ob der immer aktuell ist und auch
wirklich alle Verzeichnisse abklappert?
Probier mal das hier:
1
dir c:\scan*jpg /s
Wenn das nichts findet, hilft nur noch der Einsatz eines
Datenwiederherstellungsprogrammes à la GetDataBack.
Photorec, falls die anderen Tools, die versuchen, die Reste der MFT zu
verwerten, nicht klar kommen, bzw. fals dir /s nix mehr findet. Photorec
macht einen QuerFeldein-Scan, und sucht nach bekannten Dateiheadern, und
speichert die in der richtigen Größe ab (ob aber auser einem intakten
Header wirklich nützliche Daten im File stehen, hängt davon ab, ob die
Dateien bzw. einiger derer Sektoren bereits mal überschrieben wurden).
jpg-Files sind damit ein Klacks, falls nicht schon irgendwie (teilweise)
überschrieben.
for ($i=96;$i<301;$i+=2)
{
$v=sprintf("move scan%03d.jpg /tmp\n",$i);
system($v);
}
also nach "/tmp" geschoben..... wo soll das den sein auf einen WIN
Rechner ?
Kann es seind du nun alles Dateien IN eine Datei verschoben hast ?
Im aufgeruffenden Verzeichnis müsste also eine /tmp Datei liegen.
Mit allesn Bilder schön hintereinader weg....
Rufus Τ. Firefly schrieb:> Vollidiot... schrieb:>> Dann hätte die Windowssuche sie doch finden müssen?!>> Nicht zwingend, die durchsucht ja nicht unbedingt das Dateisystem,> sondern nur irgendeinen Index, und ob der immer aktuell ist und auch> wirklich alle Verzeichnisse abklappert?
Also so wie die Festplatte gerödelt hat glaube ich nicht dass da nur
irgendein Index durchsucht wurde...
Aber anyway
> dir c:\scan*jpg /s
findet auch nichts.
Jens G. schrieb:> Photorec
Puh, das ist eine Sache für sich. Das Dingen hat mir innerhalb ca. 30
Minuten sagenhafte 74649 Dateien in 150 Ordnern mit insgesamt 3,9GB
erzeugt, natürlich auf einer anderen Partition. Nebenbei wurde mehrfach
mein Antivirenprogramm getriggert, vermutlich irgendwelche Reste die da
aus den ewigen Binärgründen rausgepuhlt worden sind.
Ein schneller Test (dir /s /b *.jpg >liste.txt und die Liste als
Slideshow mit Irfan View öffnen) sagt aber: 0 Treffer. Dieses move
scheint ein toller Datenschredder zu sein, muss ich mir merken...
Marc schrieb:> also nach "/tmp" geschoben..... wo soll das den sein auf einen WIN> Rechner ?
Das ist die 1-Million-Euro-Frage! Windows\Temp ist es jedenfalls nicht.
> Kann es seind du nun alles Dateien IN eine Datei verschoben hast ?> Im aufgeruffenden Verzeichnis müsste also eine /tmp Datei liegen.> Mit allesn Bilder schön hintereinader weg....
Da ist leider gar nichts. Aber das bringt mich auf eine Idee was ich
noch versuchen kann.
Danke erstmal für die (leider bisher erfolglose) Hilfe!
So, jetzt habe ich mal Process Monitor ausgepackt und die Situation
nachgestellt. Stürzt zwar ständig ab aber für die paar Sekunden hat es
gereicht...
Marc (Gast) hatte teilweise Recht. Es wird eine Datei "tmp" erzeugt,
allerdings nicht im aktuellen Verzeichnis sondern auf C:\ und diese
enthält leider auch nur das letzte verschobene Bild... Das war es dann
wohl.
Rätsel gelöst, Daten futsch, Vollidiot hat seinen Namen verdient...
Nebenbei bemerkt, es ist schon erstaunlich was Datenrettungsprogramme
wie Photorec so alles hervorzaubern. Leider sind zumindestens bei *.mp3
und *.avi die meisten Dateien unlesbar... Bei einfachen Formaten wie *.h
(24000 Stück!) und *.txt (34000) sieht es natürlich besser aus. Boah,
wie gut dass ich keine solche Datei suche, da würde man ja nie fertig!
Vollidiot... schrieb:> Marc (Gast) hatte teilweise Recht. Es wird eine Datei "tmp" erzeugt,> allerdings nicht im aktuellen Verzeichnis sondern auf C:\ und diese> enthält leider auch nur das letzte verschobene Bild... Das war es dann> wohl.
Wobei ich davon ausgegangen bin das du alles in eine Datei verschoben
hast
also eher verkettet wie in einem Tar archive
aber das wäre dann eher move * Datei. und nicht in einer For Schleife
jedes einzeln verschieben...das habe ich überlesen..
aber der ansatz war schon Richtig
>Nebenbei bemerkt, es ist schon erstaunlich was Datenrettungsprogramme>wie Photorec so alles hervorzaubern. Leider sind zumindestens bei *.mp3>und *.avi die meisten Dateien unlesbar... Bei einfachen Formaten wie *.h>(24000 Stück!) und *.txt (34000) sieht es natürlich besser aus. Boah,>wie gut dass ich keine solche Datei suche, da würde man ja nie fertig!
Naja, ich hätte Dich noch warnen müssen: das Ding holt Dir Deine ganze
Vergangenheit wieder hervor, sofern noch nicht überschrieben.
Aber da Du mit Deinem Move nun alle Files "aufeinandergestabelt" hast,
findet man mit Photorec natürlich nix mehr (auser die letzte)
Jens G. schrieb:> Aber da Du mit Deinem Move nun alle Files "aufeinandergestabelt" hast,> findet man mit Photorec natürlich nix mehr (auser die letzte)
Aber "move" macht doch auch nichts anderes, als erst die Dateien zu
kopieren und anschließend die Quellen zu löschen. Dann müssten die
Quelldateien, im Rahmen der üblichen Einschränkungen, wiederherstellbar
sein.
J.-u. G. schrieb:> Aber "move" macht doch auch nichts anderes, als erst die Dateien zu> kopieren und anschließend die Quellen zu löschen.
Nein, das Windows-eigene "move" macht das nur, wenn
laufwerksübergreifend verschoben wird. Innerhalb eines Laufwerkes wird
da gar nichts kopiert, da werden nur Verzeichniseinträge umgehängt.
Marc schrieb:> also nach "/tmp" geschoben..... wo soll das den sein auf einen WIN> Rechner ?
Weshalb sollte es diesen Ordner in Windows nicht geben dürfen?
Rufus Τ. Firefly schrieb:> Innerhalb eines Laufwerkes wird> da gar nichts kopiert, da werden nur Verzeichniseinträge umgehängt.
Ja. Im vorliegenden Fall wurde demnach jede einzelne Quelldatei, eine
nach der anderen, "umgehängt". Die eigentlichen Inhalte der Quellen
werden aber noch irgendwo auf der Partition vorhanden sein und sollten
mittels Recovery-Programmen restaurierbar sein.
A. K. schrieb:> Weshalb sollte es diesen Ordner in Windows nicht geben dürfen?
Es müsste ihn jemand eigens angelegt haben, von Haus aus gibt es das
nicht, sondern ein vom angemeldeten Benutzer abhängiges Temp-Verzeichnis
(Environmentvariable %temp%) und ein für das System selbst zuständiges
unterhalb von %systemroot%, also c:\windows\temp.
Rufus Τ. Firefly schrieb:> Es müsste ihn jemand eigens angelegt haben,
Richtig. Aber er schrieb:
> Der Ordner tmp ist leer.
Wenn das also nicht grad eine Aussage der Art "Das Einhorn war grün"
war, dann schliesse ich daraus, dass es einen solchen Ordner gab. Wobei
sich zwischenzeitlich herausstellte, dass er doch von Einhörnern
phantasierte. Je nun...
Stimmt - eigentlich sollten die Quellfiles gar nicht angefaßt worden
sein (auser deren Verzeichniseinträge) - es sollten eigentlich die
Quellfiles wirklich noch da sein für Photorec.
J.-u. G. schrieb:> Die eigentlichen Inhalte der Quellen> werden aber noch irgendwo auf der Partition vorhanden sein und sollten> mittels Recovery-Programmen restaurierbar sein.
Tja, das dachte ich auch aber offensichtlich ist dem nicht so. Wenn ich
Zeit finde stelle ich das ganze mal auf einem USB-Stick nach, da kann
ich dann mal mit verschiedenen Programmen rumspielen ohne jedes mal eine
halbe Stunde warten zu müssen...
A. K. schrieb:> Rufus Τ. Firefly schrieb:>> Es müsste ihn jemand eigens angelegt haben,
Genau so ist es. Der Ordner tmp wurde von mir manuell per Explorer
angelegt.
> Wobei> sich zwischenzeitlich herausstellte, dass er doch von Einhörnern> phantasierte. Je nun...
???
Also was Datenrettung angeht, da schwör ich auf GetDataBack, hatte auch
schon verschiedentlich Datenverluste und bis auf nen Headcrash hab ich
damit praktisch alles wieder hervorgeholt.
Aber halt ganz wichtig, von der Platte erst n komplettes Image ziehen,
weil durch die Programminstallation evtl. Daten überschrieben werden.
Oder alternativ die Platte ausbauen und an nem anderen Rechner die
Rettung laufen lassen ... auch das surfen im Netz kann schon Daten
überschreiben durch den Cache.
Hallo,
in der ct gab's vor ein paar jahren mal einen Artikel zur Datenrettung.
Ganz wichtig: nie auf der Originalplatte arbeiten, sondern immer eine
Kopie ziehen. Gerade Bilder werden mit den dort angegebenen Programmen
sehr zuverlässig gefunden. Habs mal mit der Speicherkarte der Kamera
durchgeführt und mich gewundert, wo ich schon überall war.
Gruß, Yupp
A. K. schrieb:> Marc schrieb:>> also nach "/tmp" geschoben..... wo soll das den sein auf einen WIN>> Rechner ?>> Weshalb sollte es diesen Ordner in Windows nicht geben dürfen?
/tmp kann es nicht geben. das ist ein UNIX Pfad.
\tmp gerne auf dem gesetzen laufwerk gerne.
aber "/tmp" ist ungültig.
>/tmp kann es nicht geben. das ist ein UNIX Pfad.
Der / funktioniert bei Windowsen AFAIK seit Jahrzehnten genausogut.
Dieser Code (in "Eigene Dateien" gespeichert und ausgeführt) tut, was
man erwartet und verschiebt die drei gewünschten Files aus selbigem
Ordner in den vorher manuell angelegten Ordner 'C:\tmp'.
1
for ($i=1; $i<4; $i+=1)
2
{
3
$v=sprintf("move text%d.txt /tmp\n",$i);
4
system($v);
5
}
Allerdings unter W2k (die einzige griffbereite virtuelle Maschine mit
etwas Windows-ähnlichem)...
Marc schrieb:> /tmp kann es nicht geben. das ist ein UNIX Pfad.> \tmp gerne auf dem gesetzen laufwerk gerne.> aber "/tmp" ist ungültig.
Ausprobiert oder bloss behauptet?
Tatsache ist: Der Windows API akzeptiert beide Schreibweisen. Was die
Kommandozeilen-Anwendungen damit anstellen ist ein anderes Thema. MOVE
jedenfalls akzeptiert /tmp zumindest als Zielangabe.
verschiebt die Datei in eine Datei Namesn tmp im aktuellem Root des
Laufwerkes.
Existiert schon ein Ordner mit dem Namen dann wird in diesen verschoben.
1
C:\>mkdir tmp
2
3
C:\>echo hallo > test.txt
4
5
C:\>move test.txt /tmp
6
1 Datei(en) verschoben.
7
8
C:\>cd tmp
9
10
C:\tmp>dir
11
Verzeichnis von C:\tmp
12
13
06.12.2012 15:44 <DIR> .
14
06.12.2012 15:44 <DIR> ..
15
06.12.2012 15:44 8 test.txt
16
1 Datei(en), 8 Bytes
17
2 Verzeichnis(se), 116.262.928.384 Bytes frei
Getestet unter Win7 ging aber schon unter Win98/98 und ich meine MSDOS
6.0 genauso.
Wenn die Datei schon existiert erscheint aber normalerweise eine Abfrage
1
C:\tmp>move test.txt tmp
2
1 Datei(en) verschoben.
3
4
C:\tmp>echo hallo2 > test.txt
5
6
C:\tmp>move test.txt tmp
7
C:\tmp\tmp überschreiben? (Ja/Nein/Alle):
Hier muss also (neben der fahrlässigkeit ein völlig ungeprüftest Skript
auf nicht gesicherte Produktivdaten loszulassen) eigentlich noch diese
Abfrage unterdrückt oder per Skript bestätigt worden sein --> doppelt
dämlich... oder die Dateien existieren halt noch am Ursprungsort
abzüglich der ersten die nun tmp heißt.
Thread beobachten
Seitenaufteilung abschalten