"löschen wird vorbereitet..."

[neustadt]

es ist ja eine bekannte sache, dass windows seit vista für alle möglichen lese/schreib vorgänge die dafür benötigte zeit berechnen will. dumm nur wenn die berechnung ca. 100x so lange dauert wie der eigentliche vorgang.

http://img684.imageshack.us/img684/8382/unbenanntit.png

als ich vor ca. einem jahr von linux (gentoo) auf windows 7 umgestiegen bin habe ich gleich nach einer möglichkeit diese bescheuerte berechnung zu umgehen bzw. zu deaktivieren. damals erfolglos.

und heute regt mich dieses verhalten wieder dermaßen auf, dass ich aufs neue auf der suche bin diesen quark zu umgehen. wieder erfolglos. es sei denn jemand hier im forum kennt ein tool/geheimen-reg-schlüssel/irgendwas um mich von meinem leid zu erlösen.

thx!

alternativ wäre ich an reiser4 patches für den windows kernel interessiert :freak:

[HeldImZelt]

Ich bin mir nicht sicher, ob das wirklich nur sinnlose Zeit ist, die da vergeudet wird. Aufgefallen ist es mir aber auch schon. Interessant zu wissen wäre, was da einen Flaschenhals bildet, CPU oder HDD.

Versuche mal via Total Commander oder Konsole zu löschen.

[DarkFox]

Scheinbar wird auch schon während dieser Berechnung gelöscht/geschrieben. Nervig find ichs aber auch.

[neustadt]

Konsole bringt keinen Geschwindigkeitsvorteil und TC ist noch langsamer.
Was mich wundert ist, dass Windows zum löschen länger braucht, als das entpacken des entsprechenden Archives dauert. Wie kann das sein? Beim entpacken muss das Dateisystem verändert werden + die Daten geschrieben werden + entpackt werden.
Beim löschen fallen die Punkte 2 und 3 weg.
Ich kann mir das nur erklären, indem Windows erstmal alle Dateien einliest, bevor es sie löscht. Wozu soll das gut sein?

Bei Windows 2003 und Windows 2008 kann das doch nicht auch der Fall sein. Was wäre denn das für ein Server Betriebsystem?

[Asaraki]

Konsole bringt keinen Geschwindigkeitsvorteil und TC ist noch langsamer.
Was mich wundert ist, dass Windows zum löschen länger braucht, als das entpacken des entsprechenden Archives dauert. Wie kann das sein? Beim entpacken muss das Dateisystem verändert werden + die Daten geschrieben werden + entpackt werden.
Beim löschen fallen die Punkte 2 und 3 weg.
Ich kann mir das nur erklären, indem Windows erstmal alle Dateien einliest, bevor es sie löscht. Wozu soll das gut sein?

Bei Windows 2003 und Windows 2008 kann das doch nicht auch der Fall sein. Was wäre denn das für ein Server Betriebsystem?

Vorweg, ich kenne die Vorgehensweise von Windows nicht. Aber :

Löschen kann durchaus länger gehen als das Erstellen. Das ist so nicht auszuschliessen - in grossen Datenbanksystemen sieht das z.B. sehr ähnlich aus, weshalb oft ein Wartungsfenster für grössere Löschaktionen verwendet wird. Die Gründe da sind, dass für den Insert (in meinem Beispiel) der freie Anteil einer Page verwendet wird. Ich könnte mir also denken, dass Windows bei neuen Files ja schon im Voraus weiss wohin diese geschrieben werden (in den nächst freien Platz der HDD). Beim Löschen ist dieser Zugriff aber durch die zu löschenden Files gegeben und diese müssen qualifiziert stattfinden.

Ich könnte mir zumindest denken, dass diesbezüglich das Verhalten auf Insert/Update Performance ausgelegt wurde und der Delete bewusst länger braucht.

[Der_Donnervogel]

Ich bin auch nicht mit den Details von NTFS vertraut, aber so viel ich weiß basiert es intern auf irgend einem B-Baum. Löschen kann bei B-Bäumen aber aufwändig sein, falls Knoten nicht mehr den nötigen Füllungsgrad aufweisen und der Baum deshalb rebalanciert werden muss. Vor allem wenn man viele Dateien löscht, wird man aber um Rebalancierungen nicht herum kommen. So eine Rebalancierung kann unter Umständen größere Teile eines Baumes betreffen. Gut möglich, dass das Zeit kostet. Vor allem kann ich auch nicht einschätzen ob hier auch noch das Journaling hinein spielt und die ganze Sache weiter verzögert, da ja auch noch das Journal geführt werden muss. Da ich mich aber mit NTFS nicht tiefer greifend beschäftigt habe, kann ich da auch nur nach der Ursache raten, warum löschen langsam ist. ;)

[Lokadamus]

mmm...

Da das erst seit Vista länger dauert als bei XP, kann es nur daran liegen:
http://de.wikipedia.org/wiki/NTFS#Erweiterungen_seit_Windows_Vista

[neustadt]

mmm...

Da das erst seit Vista länger dauert als bei XP, kann es nur daran liegen:
http://de.wikipedia.org/wiki/NTFS#Erweiterungen_seit_Windows_Vista

Am ersten Punkt sollte es nicht liegen, da es nicht um Löschvorgänge geht.

Wenn es am atomaren Dateisystem liegt wäre es schon eine schlechte Implementierung. Ich werde gleich mal eine live CD booten und einen paar delete benchmarks fahren. Reiser4 ist ja nicht gerade für seine delete Geschwindigkeit berühmt, bin aber trozdem überzeugt, dass es native-ntfs schlagen wird. ntfs-3g sowieso.

[Rudi ratlos]

In einem anderen Forum habe ich den hinweis gefunden, dass ich zuerst den ganzen Ordner verschieben, und danach löschen soll. Das Löschen von ca. 4GB hat zwar immer noch ca. 4 Minuten gedauert, aber es hat gelöscht.

[rmdd53]

Mal direkt löschen probiert?
Also nicht erst in den Papierkorb verschieben.
Kannst du unter Eigenschaften für den Papierkorb für jeden Partition separat einstellen.

[Gast]

Hallo zusammen!

Ich bin Systemadministrator und "löschen wird vorbereitet..." gehört zu meinem absoluten Lieblingsmeldung unter Windows! - Dinge, die die Welt nicht braucht!!!

Mir ist aber aufgefallen dass viele Missverständnisse und Gerüchte über diese Meldung kursieren und so wollte ich die Sache an dieser Stelle mal aufklären:
Nein, da sitzt dann niemand OM-singend in der Ecke um sich auf die Aufgabe vorzubereiten! :D
Während dieser Vorbereitung - beim löschen oder kopieren - geht das System sämtliche zu löschende/kopierende Dateien durch und ermittelt deren Größe. Diese Dateigrößen werden beim eigentlichen Vorgang für die Zeitberechnung benötigt, die nachher dann sowieso nie stimmt! ;)

Dass das tatsächlich so ist, könnt Ihr in einem einfachen Versuch selbst herausfinden: Einfach vor dem Löschen/Kopieren den entsprechenden Ordner über rechte Maustaste, Eigenschaften die Größe berechnen lassen. Wurde diese komplett ermittelt, wird der anschließend angestoßene Lösch-/Kopiervorgang sofort begonnen, da sich die benötigten Informationen nun noch im Cache des Systems befinden.
Zeit kann man dadurch allerdings nicht sparen, da die Ermittlung der Eigenschaften genauso lange dauert, wie beim direkten Löschen (ohne Ermittlung der Eigenschaften) mit der Meldung "Löschen wird vorbereitet...".

Der Rat, zuerst den ganzen Ordner zu verschieben und danach zu löschen, hat den gleichen Effekt wie bei der Ermittlung der Eigenschaften (auch hier stehen anschließend die Dateigrößen im Cache), benötigt allerdings etwas mehr Zeit, da das Dateisystem zusätzlich umgeschrieben werden muss.

Abschalten lässt sich dieser Quatsch der Zeitberechnung leider nicht! Doch für erfahrene PC-Anwender empfiehlt sich zumindest für das Kopieren der xcopy-Befehl. Dabei erspart man sich das vorherige Ermitteln der Dateigröße und mit dem Parameter /y kann zusätzlich sogar auf die nevigen Zwischenfragen verzichtet werden!

Viele Grüße
e-gon

[Gast]

Bei Totalcommander in den Einstellungen bei Kopieren/Löschen einen Haken bei "Benutze Explorer-Löschmethode".

Das Löschen geht dann äußerst schnell, ohne diese dümmliche Berechnung...

[Gast]

Meines Erachtens hat dies mit der USN Journal Funktion von NTFS zu tun.
Die ist bei Win 7 per Standart aktiviert.
Hier werden VOR Änderungen im Dateisystem die zu beabsichtigten Aktionen z.b pro Datei gespeichert/geschrieben.
Wenn man also eine Datei abc löschen will, schreibt er vor dem Löschvorgang erst ins USN Journal das Datei ABC gelöscht werden soll und löscht dann Datei abc. Danach schreibt er wieder ins USN Journal, Datei ABC wurde gelöscht.

Werden also 50000 Dateien gelöscht muss er diese Information (dateien sollen gelöscht werden) auch 50000 mal ins USN Journal schreiben.Dafür braucht er halt etwas Zeit. Die Berechnung der Zeit des Löschvorgangs ist eine "Nebenwirkung" dieses Vorgangs und meines Wissens nicht für die Verzögerung verantwortlich.

Das Seminar zu dem Thema liegt aber schon eine Weile zurück, möglich das ich das auch falsch in Erinnerung habe.

[Gwaihir]

Ohja, besonders lustig wirds nämlich, wenn man versucht 30 Dateien von einer USB-Diskette zu löschen... habe gestern 10 Minuten und mehrere Anläufe gebraucht um eine Diskette zu löschen... formatieren wollte er nämlich nicht, weil er einfach irgendwas auf der Diskette rumliest und oben dieser grüne Balken von links nach rechts läuft und er schlicht und ergreifend keine Zeit für das Kontextmenü hat... völlig idiotisch...

[Gast]

Was soll der xcopy Befehl sein?

[Gästle]

Wenn ich die Daten direkt lösche (also Shift+Entf) habe ich keine Berechnungszeit. Könnte aber auch an der SSD liegen?

[ShadowXX]

Was soll der xcopy Befehl sein?
Das ist ein Kommandozeilen-Befehl...

[airbag]

Ich bin auch nicht mit den Details von NTFS vertraut, aber so viel ich weiß basiert es intern auf irgend einem B-Baum. Löschen kann bei B-Bäumen aber aufwändig sein, falls Knoten nicht mehr den nötigen Füllungsgrad aufweisen und der Baum deshalb rebalanciert werden muss. Vor allem wenn man viele Dateien löscht, wird man aber um Rebalancierungen nicht herum kommen. So eine Rebalancierung kann unter Umständen größere Teile eines Baumes betreffen. Gut möglich, dass das Zeit kostet. Vor allem kann ich auch nicht einschätzen ob hier auch noch das Journaling hinein spielt und die ganze Sache weiter verzögert, da ja auch noch das Journal geführt werden muss. Da ich mich aber mit NTFS nicht tiefer greifend beschäftigt habe, kann ich da auch nur nach der Ursache raten, warum löschen langsam ist. ;)


Kann gut sein, da bei einem Mehrwegbaum(B-Baum) ein gelöschter Wert im Knoten dann auch als Referenz zu den Werten in unterstehenden Knoten dient. Von daher müsste man den Baum, dann "umsortieren" um die B-Baumeigenschaften, wie die "totale Ordnung" und Balance wiederherzustellen. Je nach Höhe des B-Baums könnte dies extrem viel Zeit kosten.

[qiller]

Shift-Entf?
del * /s /f ?
Linux-Live CD?
alternativer Dateimanager?
Antivirenscanner?
Index-Dienste?

Also ka, bei mir geht das selbst mit der Berechnung relativ fix: Hab grad mal nen Ordner mit 19k Dateien (~10GB) kopiert und die Anzeige der "Kopieren wird vorbereitet..." Meldung war vlt 5sek da. Danach den Ordner mit Shift-Entf gelöscht, Vorbereitungsmeldung wieder ca 5sek, Löschen hat ca genauso lang gedauert.

mfg Olli

Edit: Wenn man allerdings bedenkt, dass die Dateien ja eigt gar nicht wirklich gelöscht werden, sondern nur die MFT-Einträge geändert werden...hm^^

[tam tam]

Versucht es mal mit Ausschneiden(Strg+X), dann auf Papierkorb doppelklicken und da Einfügen(Strg+V). Eben bei mir getestet, knappe 23GB(ca. 145k Dateien) innerhalb von 30s gelöscht. Und ich glaub, um so kleiner die Dateien sind, um so länger dauerts sowieso.

[seneca]

Ja, kleine Dateien sind ein graus.

Wir mußten mal ~80GB in ~200k Dateien von einem alten Server auf einen neuen kopieren.
Das dauerte etwa 13 Stunden.

Löschen tue ich sowas immer mit del * /s /f in der console. Das geht dan einigermaßen schnell.

[Gast]

Das ist ein Kommandozeilen-Befehl...

Und wie kann ich xcopy als Kommandozeilenbefehl nutzen?

[Shink]

und heute regt mich dieses verhalten wieder dermaßen auf, dass ich aufs neue auf der suche bin diesen quark zu umgehen. wieder erfolglos. es sei denn jemand hier im forum kennt ein tool/geheimen-reg-schlüssel/irgendwas um mich von meinem leid zu erlösen.

thx!

alternativ wäre ich an reiser4 patches für den windows kernel interessiert :freak:
Naja, du könntest glaub ich z.B. EXT-FS verwenden: Windows auf eine kleine NTFS-Partition und alles andere auf eine EXTFS-Partition.

Schuld ist tatsächlich das Dateisystem. Besonders lustig sind Dinge wie Build von Programmierprojekten: Da hat man hunderttausende Files die ein paar Mal am Tag gelöscht werden.

Lösungen die wirklich helfen:
- Man löscht nicht sondern verschiebt. Dies macht prinzipiell nichts anderes als ein Umbenennen und geht sehr schnell. Papierkorb ist auch das selbe: Da wird einfach verschoben.
- Anderes Filesystem. Am besten gleich das Betriebssystem mitändern.:wink:
- Wenn man weiß dass man für einen Anwendungszweck oft löschen muss: RAM-Disk verwenden.

Da das erst seit Vista länger dauert als bei XP, kann es nur daran liegen:
http://de.wikipedia.org/wiki/NTFS#Erweiterungen_seit_Windows_Vista
Es dauert auch unter XP lange. Der Dialog wurde allerdings geändert.:freak: Unter XP glaubt man der Explorer hat sich aufgehängt.

Könnte aber auch an der SSD liegen?
Ja.

[Rooter]

Evt. wird das hier ja auch das Löschen verbessern:
Windows 8: Bessere Kopierfunktion, weniger Dialoge (http://www.computerbase.de/news/2011-08/windows-8-bessere-kopierfunktion-weniger-dialoge/)

MfG
Rooter