In diesem Blog-Beitrag möchte ich ein mögliches Problem beim Entpacken von ZIP-Dateien unter Windows 10 V1809 zur Diskussion stellen. Der Explorer hängt sich möglicherweise beim Entpacken auf.
Anzeige
Die Verarbeitung von ZIP-Archiven war direkt nach Freigabe von Windows 10 V1809 ja auf Grund eines Fehlers nicht problemlos nutzbar (siehe Links am Artikelende). Microsoft hat diesen Fehler aber gepatcht. Nun hat mir Blog-Leser Martin Feuerstein Ende April 2019 eine Beobachtung per Mail zukommen lassen, die möglicherweise auf einen Fehler hindeutet. Hier sein Szenario:
- Windows 10 Version 1809, Updatestand April 2019
- Virenscanner abgesehen vom Windows Defender
- Versuch, ZIP-Archive zu entpacken
Das Problem tritt beim Entpacken/Verschieben von Dateien in einem ZIP-Archiv mit dem Windows-Explorer auf. Martin schreibt dazu:
Die ZIP-Datei habe ich über AirDroid Web vom Mobiltelefon heruntergeladen (also ohne Kompression in ZIP eingepackt).
Die heruntergeladenen Dateien wollte ich aus der ZIP-Datei in einen Ordner verschieben (und dabei aus der ZIP-Datei entfernen lassen). Ich hätte natürlich die Dateien wie bei 7-Zip entpacken, im Windows Explorer kopieren und anschließend die ZIP-Datei löschen können – aber ich wollte das direkt mittels Verschieben lösen.
Dabei hat sich der Explorer mehr oder weniger aufgehängt. Ich habe den Vorgang nach mehreren Minuten dann per Klick im Kopier-Dialog abgebrochen, was dann noch ca. 30 Sekunden benötigte. Es wurden dann schlussendlich auch alle ausgewählten Dateien in den Zielordner geschrieben und in der ZIP-Datei gelöscht.
Den Explorer musst ich dazu nicht per Task-Manager beenden und neustarten. An der Leistung des Computers/Speichers dürfte es nicht liegen (Xeon E3, 16 GB RAM, Quelle Ordnerumleitung auf Server/Offline-Cache auf SSD, Ziel SSD). Inhalt der ZIP-Datei waren 5 Fotos, zusammen 14,9 MB, also nichts, was die Hardware zum Schwitzen bringen dürfte.
Ich selbst habe aktuell kein Windows 10 V1809-Testsystem. Auf einem Windows 10 V1903-Testsystem ließ sich dieses Verhalten nicht nachvollziehen. Daher meine Frage: Irgend jemand von euch, der unter Windows 10 ein Aufhängen des Explorers beim Arbeiten mit ZIP-Archiven beobachtet hat, wenn die Dateien beim Entpacken aus dem Archiv sofort gelöscht werden sollen?
Ähnliche Artikel:
Windows: Merkwürdige ZIP-Handhabung im Explorer
Windows 10 V1809: Schreib-Bug in ZIP-Funktion
Windows 10 V1809: ZIP-Bug von MS bestätigt
Windows 10 V1809: Update KB4464455 fixt ZIP-Bug
Windows: ZIP-Datei liefert Fehler 0x80004005 beim Öffnen
Anzeige
Anzeige
explorer?
Den nutzt man ja auch nicht!
=> TotalCommander – auch in der eig. Testversion dauerhaft und ohne Einschränkung nutzbar.
Mit sehr vielen besten Funktionen im Bereich Dateiverwaltung. Die der explorer all nicht hat. (Ent-)Packen sowieso. Problemlos.
Hat zudem als erster die Probleme mit der fehlerhaften winrar-Datei "UNACEV2.DLL" gelöst.
von daher…
;)
Die "AirDroid"-Software behandelt die Dateien sicher anders als Windows und wird sicher vom AV-Programm überprüft, was beim Defender aufgrund der Schwierigkeiten mit der zip-Datei (eventuell kein Orginales Zip-Format) dauern kann.
"Virenscanner abgesehen vom Windows Defender" was heist das, das nur der Defender drauf ist oder mehr?
AirDroid Web – als Webanwendung, die auf dem Telefon ausgeführt und im Browser des Desktop aufgerufen wird – packt beim Download mehrerer Dateien diese ohne Kompression in ein ZIP-Archiv (so, wie man es bei WinZip oder 7-Zip auch auswählen kann), mehr Hexenwerk ist bei den per AirDroid heruntergeladenen ZIP-Dateien auch nicht bei.
Und ja, nur der Defender. Heißt nicht, dass der schuld/nicht schuld ist. Zumindest kein Virenscanner von Drittanbietern.
Mich ärgert momentan eher was anderes, bin aber noch nicht dahinter gekommen, wo das Problem liegt. Wollte gestern von zwei SD-Karten, die ich mit meiner Nikon D7200 vollgeknipst hatte, alle Bilder auf die lokale Festplatte verschieben. Erst dachte ich an eine der üblichen Eigenmächigkeit des Explorers (auch 1809), dass ich nur die Option "Kopieren", nicht aber "Verschieben" angezeigt bekomme, auch STRG+X/STRG+V wurde mir verweigert. Bis ich dann festgestellt habe, dass die beiden SD-Karten komplett als Schreibgeschützt gemountet wurden, egal wie der Schreibschutzschalter der Karten gesetzt war. In der Kamera funktioniert es aber wie gewohnt. War mir dann aber gestern Abend zu spät für weiteres Debugging. Hat jeman eine Idee?
Hatte ich mit meiner D7200 auch schon unter anderen Systemen alsWindows …
Das liegt nach meiner Erfahrung daran, dass die Stellung des Schreibschutz-Schiebers durch den Kartenleser nicht erkannt wird. – Warum auch immer: Es ist alles denkbar.
Vorgangsweise: Kopieren und den SD-Chip in der Kamera formatieren. Danach funktionieren diese Chips meistens wieder richtig. (Warum? – Keine Ahnung!)
Ausser: Der Schreibschutz-Schieber ist herausgefallen. (Kommt leider immer häufiger vor, besonders bei SanDisk-Chips.) In diesem Fall kann man versuchen -so wie einst bei den CompactCassetten- einen Klebstreifen möglichst großflächig (damit er nicht im Kartenleser kleben bleibt) darüber zu kleben. Die sicherste Methode in diesem Fall allerdings ist: kopieren und Chip wegschmeißen.
Wenn sich aber auch neue Chips einer Löschung/Verschiebung widersetzen, sollte der Kartenleser ersetzt werden. Eine Reparatur lohnt sich bei den paar Euronen, die sowas kostet nur in Ausnahmefällen.
HTH Wolfgang
Ist der Kartenleser im Gerät oder ein Externer USB-Card-Reader.
Könnte ein Treiberproblem sein. Kameras bei mir von Canon und Samsung, kein Problem mit den Karten.
Wenn ein eingebauter Kartenleser genutzt wird mal einen USB-Card-Reader testen, löst vielleicht auf die schnelle das Problem.
Könnte auch eine nicht funktionierende Funktion an der Speicher-Karte sein.
Wie geschrieben, der Schreibschutzschalter funktioniert, wenn die SDs in der Kamera sind. Der Kartenleser ist in einem HP Pavillon X360 Subnotebook. Beim letzten Mal Karten abräumen funktionierte das noch. Ich wüsste nicht, was ich außer den obligatorischen Windowsupdates seit dem geändert habe.
Ob der Schreibschutzschalter in der Kamera funktioniert oder nicht, ist für das Problem unerheblich, denn dort kann ja der Schreibschutz-Sensor funktionieren, während der Sensor im PC oder Notbuch eben nicht funktioniert. Dieser Schalter ist ja nur ein Stückchen Plastik, das eine Lücke ausfüllt. Wichtig ist daher nur, ob der Sensor das Vorhandensein dieser Lücke erkennt (oder eben nicht). Und dieser Sensor ist ein winzig kleiner mechanischer Schalter (Mikro-Switch), der bei einer die Lücke geschlossen bleibt oder aber geöffnet wird, wenn die Lücke fehlt. Dabei ist kein bißchen Extra-Software und schon gar kein "Treiber" im Spiel. Einen mechanischen Schalter abfragen kann ein Betriebssystem schon selber. Somit reduziert sich die Frage hier einzig und allein darauf: Ist vielleicht der eingebaute Sensor-Schalter hinüber, weil z.B. "innerlich" verbogen oder ganz abgebrochen?
Und, sorry, "das letzte Mal ging's noch" ist auch kein Argument, denn genau da kann der Fehler entstanden sein. (Eine einmal verkehrt herum eingesteckte SD-Karte kann da schon ausreichen.)
Aber all das läßt sich ganz leicht mit einem extern angeschlossenen USB-Kartenleser verifizieren. So wie Herr IngoW und ich schon weiter oben geschrieben haben.
HTH Wolfgang
Guten Tag Herr Born,
so ein ähnliches Problem habe ich wenn ich WinRAR Dateien egal welcher größe runterlade und im Windows Explorer auf meiner Partition "D" (nur "C" und "D" vorhanden) mit 2 TB HDD entpacke . Das entpacken funktioniert einwandfrei. Nur das öffnen der entpackten Datei gerät ins wanken. Es kommt die Meldung "Keine Rückmeldung". Nachdem sich der Explorer wieder gefangen hat, kommt oben im Explorer Adressfeld der "Grüne" Balken und läuft von links nach rechts durch. Erst danach kann ich mit den entpackten Daten in der Datei arbeiten.
Hier gibt es keine Probleme beim Verschieben von Dateien/Verzeichnissen aus einem ZIP-Archiv. Ich habe die ZIP-Datei des Notepad++-Plugins NppExec zum Testen verwendet.
OS: Windows 10 v1809 Build 17763.437 (KB4495667 noch nicht installiert).
Was passiert denn bei selbst erstellten (per Explorer, per 7ZIP) ZIP-Dateien? Was passiert mit vom Smartphone heruntergeladenen ZIP-Dateien, die etwas anderes als die problematischen Bilder enthalten?
Interessant wäre, ob andere genau dieses Problem so nachvollziehen könnten.
Mittlerweile habe ich allerdings auch schon das Mai-Update drauf.
Nun einfach mal 5 Random-Dateien aus meinem Download-Ordner mit 7-Zip in eine ZIP-Datei ohne Kompression gepackt (bunt gemischt… MSI, 7z-Datei, EXE)… und per Explorer aus der ZIP-Datei in einen lokalen Ordner verschoben, Sache von Sekunden.
Dann nochmal vom Telefon mit AirDroid 48 Fotos (50 MB) heruntergeladen und entpackt… kopieren ging noch gut durch (7 Sekunden), verschieben per Windows-Explorer dauerte schon 1:12 – wenn auch ohne "keine Rückmeldung".
Nochmal von einem Netzwerkshare ohne Offline-Cache auf die SSD verschoben: 45 Sekunden. Und von ZIP auf SSD nach SSD: 17 Sekunden.
Nochmal zum Vergleich: Explorer-Entpacken (Kopieren) von Netzwerkshare auf SSD: 5 Sekunden, von SSD entpacken nach SSD: 4 Sekunden.
Dann nochmal Kopieren mit 7-Zip: Von Netzwerkshare nach SSD kopieren 2 Sekunden, von SSD nach SSD nochmal n Tick schneller.
Erklären kann ich mir das nicht, außer, wenn MS nach jeder verschobenen Datei (obwohl mehrere bzw. alle Dateien ausgewählt sind) die komplette ZIP neu schreibt, bevor der nächste Vorgang bearbeitet wird, was dann aber auch nicht gerade effizient wäre.
Das zuvor beschriebene "Keine Rückmeldung" ist auf demselben Computer, wenn auch mit Mai-Update, heute bei keiner Datei mehr aufgetreten.
Was passiert, wenn Du die bereits entpackten Bilder wieder in ein ZIP-Archiv verpackst (per Explorer, per 7ZIP) und dann mit dem Explorer die Bilder wieder ausschneidest?
"Erklären kann ich mir das nicht, außer, wenn MS nach jeder verschobenen Datei … die komplette ZIP neu schreibt, bevor der nächste Vorgang bearbeitet wird, was dann aber auch nicht gerade effizient wäre."
Wer hat denn gesagt, dass die Entwickler beim sympathischen Weltmarktführer immer effizienten Code schreiben?