Warum verschieben Zip-Programme immer zweimal?

Kokujou

Lieutenant
Registriert
Dez. 2017
Beiträge
929
Hallo~

Bei größeren Ordnern fällt es schnell auf. zuerst haben wir da den Prozess des Entpackens der auch im Zip-Programm (WinRar in meinem Fall) aufgezeichnet wird. Das ist wohl die Dekomprimierung. Das ist ja klar. Dann kommt aber noch ein Prozess wo das Zip-Programm quasi abschmiert und ein Verschiebe-Vorgang getriggert wird...

Bedeutet das, wenn ich mein Zip-Programm anordne etwas zu entpacken tut er das erst in ein temporäres Verzeichnes und dann erst in den Ort an den ich es haben will?

1. Warum?!
2. Gibt es Zip-Programme die Schlau genug sind die Dateien gleich an den richtigen Ort zu verpacken?
 
Ich würde mal vermuten, daß irgendeine bei Windows genutze API dafür verantwortlich ist. Es landen ja viele Dateien aus der Cloud oder Web (z.B. PDFs, Word-Dateien etc.) beim Öffnen über den Browser in einen TEMP-Ordner (C:\Users\[USERNAME]\AppData\Local\Temp).

Wenn man unter Linux oder Cygwin z.B. unzip verwendet, wird kein Zwischenordner verwendet, ebenso nicht bei gz oder tar.
 
Du solltest auch über WinRAR entpacken und nicht in WinRAR den Inhalt in den Windows Explorer ziehen!
Weiterhin sollte man immer die aktuellste Version von WinRAR verwenden.
 
Kommt halt darauf wie du es möchtest, Win Rar zb kann beides.
Nutzt du "Entpacken nach" wird direkt dort geschrieben ohne Umweg über einen Temp Ordner.
 
  • Gefällt mir
Reaktionen: HisN
7-ZIP verhält sich genauso.

Direkt entpacken läuft ohne Umweg. Drag&Drop über %TEMP%
 
  • Gefällt mir
Reaktionen: HisN
Es gibt also tatsächlich einen Unterschied ob ich explizit entpacken anklicke oder ob ich das Archiv öffne und das was ich brauche an den vorgesehenen Ort schiebe? ...

okay das ist... gut zu wissen. Auch wenn es absolut jeder logik entbehrt. Ich finds einfach schöner die Explorer-Funktionalität zu verwenden weil ich ansonsten mein halbes File-System öffnen muss, was ich nicht muss wenn ich den Ordner halt schon offen habe. aber gut, muss ich mich umgewöhnen. tut mir leid für die dumme Frage^^
 
Nö, weil über D&D die Anwendung nicht notwendigerweise das Ziel erfährt. Die kriegt den Input noch, aber wo der Output hingeschrieben werden soll, das steht wieder auf einem ganz anderen Blatt.

Explorer => gibt "unzip"-Auftrag an Tool
Tool => "unzippt" und wenn fertig, wird ein Ereignis für den Explorer ausgelöst: "bin fertig"
Der Explorer sammelt dann das Ergebnis ein.

Also muß an einen vordefnierten Pfad geschrieben werden und %TEMP% ist der einzige Pfad, von dem legitim angenommen werden darf, daß man da hinschreiben kann.

Umgehen kann man das wie erwähnt über explizite Angabe des Zielpfads, über die Konfiguration von WinRAR oder natürlich indem man das Kommandozeileninterface von winrar nutzt.
 
  • Gefällt mir
Reaktionen: ergibt Sinn
Das kann man konfigurieren? Wie und wo? :)
 
ziehst du, winrar als beispiel, eine rar, zip datei mit der rechten maustaste und nutzt das kontexmenu "hier entpacken", so wird dier inhalt direkt dorthin entpackt.
hast du das winrar offen, und ziehst eine datei/ordner mit der maus aus dem winrar fenster wohin, so wird es zuerst in den temporären pfad entpackt, und anschließend verschoben.
in winrar läßt sich ein eigener pfad für winrar-temp setzen.
 
whats4 schrieb:
ziehst du, winrar als beispiel, eine rar, zip datei mit der rechten maustaste und nutzt das kontexmenu "hier entpacken", so wird dier inhalt direkt dorthin entpackt.
hast du das winrar offen, und ziehst eine datei/ordner mit der maus aus dem winrar fenster wohin, so wird es zuerst in den temporären pfad entpackt, und anschließend verschoben.
in winrar läßt sich ein eigener pfad für winrar-temp setzen.

okay mit rechts ziehen wusste ich noch nicht. das setzen eines temp pfades war mir klar, aber das ist ja hier in dem fall nicht das problem man müsste ja den temp pfad dynamisch setzen...

trotzdem finde ich es sollte möglich sein irgendwie zu erkennen in welches fenster man die dateien zieht. also den ordnerpfad. ich meine was passiert dabei. Man zieht das programm in einen ordner, der dabei der mit dem niedrigsten Z-Index wird. kann man im Fenstermanager dabei nicht das oberste Fenster raussuchen und wenn es ein Explorer-Fenster ist dessen aktuellen Pfad rausbekommen? Wär mal n Feature.
Ergänzung ()

Nebenbei: was bedeutet in der WinRar-Welt eigentlich "sicher löschen"?
ich habe gerade etwa 60GB entpackt die wohl in nem temp ordner gelandet sind.

Also für mich heißt sicher dass die Datei etwa 20-30 mal überschrieben wird bevor sie weggeschmissen wird damit auch ja absolut gar nichts mehr lesbar ist... WinRar ist jetzt zu der Prozess ist weg und ich suche vergeblich eine 100%ige Speicher- und CPU-Auslastung^^
 
Zuletzt bearbeitet:
Um das Problem mit dem Temporären entpacken und verschieben zu umgehen haben die Programme meist ein "hier entpacken" im Kontextmenü des Explorers:

Unbenannt.png
 
ja, dafür müsste die Datei aber am Zielordner sein :p ansonsten muss man mit Dateien Entpacken den ganzen computer durchsuchen. Was recht mühseelig ist wenn man 20 Ebenen tief gehen muss. Aber ich mag den TIpp mit dem Rechtsklick-Verschieben!
 
sicher löschen: das, was es immer heisst, physikalisch überschreiben, mit nullen oder datenmüll, z.b. registerinhalt.
und das mit mehrfach ist eine geschichte, die seit jahrzehnten leider nicht stirbt.
 
Naja die Frage war ja: macht es das wirklich? Ich meine es sind 60GB die überschrieben werden müssen selbst wenn wir davon ausgehen dass es nur einmal überschreiben müsste sobald das programm geschlossen wird sofort ein riesiger löschvorgang meinen CPU leer fressen weil die ganze ZEit zufallszahlen generiert werden um das File zu überschreiben. Darum bin ich ein bischen skeptisch ob es bei wichtigen Daten nicht vielleicht besser ist den Löschvorgang auszustellen und einfach manuell ein Löschprogramm zu nehmen... Ich benutze z.B. Secure Eraser und überschreibe 35 Mal...

Ehrlich gesagt hab ich keine Ahnung ob 35 mal Löschen wirklich notwendig ist... oder auch nur 5mal. Einmal sollte doch ausreichen... Aber es existiert und im zweifelsfall - viel hilft viel
 
Den Arbeitspfad konnte man mal in WinRAR selber festlegen. Geht das nicht mehr? Hab leider grad kein windows zur Hand.

Das mit dem "mehrfach überschreiben" ist ein technisches Problem spezifisch für HDDs, was von der SSD-Jugend niemand mehr versteht. Es geht da um Restmagnetisierung der Spuren und darum, daß die reale Umsetzung, sprich das Magnetisieren des eigentlichen Datenträgers als Speichern der Information darauf nicht exakt genug ist, sämtliche vorherige Information loszuwerden; so wie ein Traktor auf der Asphaltstraße deutlich erkennbare Spuren hinterläßt, auch wenn bereits zwanzig PKWs hinterhergefahren waren.


Es darf allerdings davon ausgegangen werden, daß wenn irgendein Softwarebauer was von "sicher irgendwas" faselt und aber nicht selbst Software im "Sicher"-Segment vertreibt, daß es dann auch nicht sicher ist.
 
RalphS schrieb:
Das mit dem "mehrfach überschreiben" ist ein technisches Problem spezifisch für HDDs, was von der SSD-Jugend niemand mehr versteht. Es geht da um Restmagnetisierung der Spuren und darum, daß die reale Umsetzung, sprich das Magnetisieren des eigentlichen Datenträgers als Speichern der Information darauf nicht exakt genug ist, sämtliche vorherige Information loszuwerden; so wie ein Traktor auf der Asphaltstraße deutlich erkennbare Spuren hinterläßt, auch wenn bereits zwanzig PKWs hinterhergefahren waren.
Das ist doch schon zigmal widerlegt worden. Es gibt bis heute keinen Beweis, daß moderne HDDs ab 100 MB jemals anhand solcher "Randmagnetisierung" wieder hergestellt werden konnten.
 
https://www.heise.de/security/meldung/Sicheres-Loeschen-Einmal-ueberschreiben-genuegt-198816.html schrieb:
Sicheres Löschen: Einmal überschreiben genügt

Das Ergebnis: Ob uralte 1-GByte-Platte oder (zum Zeitpunkt der Studie) aktuelles Laufwerk, nach einmaligem Überschreiben der Daten ist die Wahrscheinlichkeit, noch etwas rekonstruieren zu können, praktisch null. Na ja, nicht ganz: Wenn es um ein einziges Bit geht, von dem man ganz genau weiß, wo es steht, dann kann man es (in einem der genannten Beispiele) mit 56 Prozent Wahrscheinlichkeit korrekt rekonstruieren. Für ein Byte müsste man dann aber schon 8 Mal richtig liegen, was nur noch mit 0,97 Prozent Wahrscheinlichkeit klappt. Tja, und bei größeren Datenmengen jenseits von einem Byte ...
 
Zurück
Oben