Hallo,
bin gerade dabei, aus großen Dateisammlungen (> 20.000) per Suche eine größere Anzahl von Dateien zu entfernen. Ist mit dem TC unmöglich. RAM-Verbrauch jagt auf 1,3 GB hoch, CPU Last steigt und kurz darauf friert das Programm ein. Mit dem Explorer sind solch große Löschaufträge problemlos möglich.
Verwende momentan TC 8.0 ß9
Löschen = Katastrophe
Moderators: Hacker, Stefan2, white
Löschen = Katastrophe
Gruß Andreas
Win10 x64 +++ Total Commander 10 +++ Directory Opus 12 +++
Win10 x64 +++ Total Commander 10 +++ Directory Opus 12 +++
Hallo, Andreas.
Steht VistaDelete=1 auch genau einmal in der aktiven wincmd.ini? Und dort auch im richtigen Abschnitt [Configuration]?
Desweiteren wäre zu prüfen, ob beim systemweiten Windows Papierkorb die Bestätigungsabfrage deaktiviert worden ist. Wenn diese deaktiviert sein sollte, also Windows Explorer verschiebt ohne Bestätigung in den Papierkorb, dann verwendet Total Commander 8.0 beta 9 nicht die mit Vista eingeführte Löschmethode, weil der Benutzer sonst nicht mehr gefragt werden könnte, ob er wirklich löschen will.
Wenn also Total Commander 8 aus dem oben beschriebenen Grund auf seine eigene Löschmethode zurückfallen sollte, dann könnte das unter Windows 7 (32-bit/64-bit) genau die Symptome hervorrufen, die du berichtet hast.
Grüße
Karl
Steht VistaDelete=1 auch genau einmal in der aktiven wincmd.ini? Und dort auch im richtigen Abschnitt [Configuration]?
Desweiteren wäre zu prüfen, ob beim systemweiten Windows Papierkorb die Bestätigungsabfrage deaktiviert worden ist. Wenn diese deaktiviert sein sollte, also Windows Explorer verschiebt ohne Bestätigung in den Papierkorb, dann verwendet Total Commander 8.0 beta 9 nicht die mit Vista eingeführte Löschmethode, weil der Benutzer sonst nicht mehr gefragt werden könnte, ob er wirklich löschen will.
Wenn also Total Commander 8 aus dem oben beschriebenen Grund auf seine eigene Löschmethode zurückfallen sollte, dann könnte das unter Windows 7 (32-bit/64-bit) genau die Symptome hervorrufen, die du berichtet hast.
Grüße
Karl
Hallo, Andreas.
Sieht fast so aus.
Als Christian mit T.C. 8.0ß7 auf Rechnern mit Vista und neuer den Vorgabewert für VistaDelete von 0 auf 1 geändert hat (zieht, wenn VistaDelete gar nicht angegeben wird), führte das prompt dazu, dass Benutzer sich beschwerten, der Total Commander lösche ohne jede Nachfrage.
Mit VistaDelete=1 zeigt nämlich nicht mehr Total Commander die Abfrage an, ob man wirklich in den Papierkorb löschen will, sondern Windows selbst. Ist diese Abfrage abgeschaltet, dann löscht also auch T.C. ohne Nachfrage in den Papierkorb.
Daher hat Christian in den nachfolgenden Betas ein paar Prüfungen eingebaut, die VistaDelete=0 annehmen, sobald z.B. die Sicherheitsabfrage des Windows Papierkorbs abgeschaltet ist.
Persönlich hatte ich das allerdings so verstanden, dass der Benutzer trotzdem T.C. zwingen kann, trotz abgeschalteter Papierkorb-Bestätigungsabfrage, die VistaDelete Methode zu verwenden, indem er selbst explizit VistaDelete=1 in die wincmd.ini einträgt. Sieht fast so aus, als wäre diese Interpretation falsch. Werde ich einfach mal ausprobieren und das Ergebnis nachtragen.
Grüße,
Karl
Sieht fast so aus.
Als Christian mit T.C. 8.0ß7 auf Rechnern mit Vista und neuer den Vorgabewert für VistaDelete von 0 auf 1 geändert hat (zieht, wenn VistaDelete gar nicht angegeben wird), führte das prompt dazu, dass Benutzer sich beschwerten, der Total Commander lösche ohne jede Nachfrage.
Mit VistaDelete=1 zeigt nämlich nicht mehr Total Commander die Abfrage an, ob man wirklich in den Papierkorb löschen will, sondern Windows selbst. Ist diese Abfrage abgeschaltet, dann löscht also auch T.C. ohne Nachfrage in den Papierkorb.
Daher hat Christian in den nachfolgenden Betas ein paar Prüfungen eingebaut, die VistaDelete=0 annehmen, sobald z.B. die Sicherheitsabfrage des Windows Papierkorbs abgeschaltet ist.
Persönlich hatte ich das allerdings so verstanden, dass der Benutzer trotzdem T.C. zwingen kann, trotz abgeschalteter Papierkorb-Bestätigungsabfrage, die VistaDelete Methode zu verwenden, indem er selbst explizit VistaDelete=1 in die wincmd.ini einträgt. Sieht fast so aus, als wäre diese Interpretation falsch. Werde ich einfach mal ausprobieren und das Ergebnis nachtragen.
Grüße,
Karl
Hallo, Andreas.
Sieht so aus, als zwinge VistaDelete=1 T.C. tatsächlich, unter Windows Vista, Windows 7, Server 2008 die VistaDelete Methode zu benutzen, obwohl die Papierkorb-Bestätigung abgeschaltet ist.
Umgebung:
Windows 7 SP1, 32-bit
Total Commander 8.0ß9 32-bit
Test 1 ohne VistaDelete in der wincmd.ini
In der wincmd.ini VistaDelete=1 entfernt, also gilt nach dem Neustart des T.C. die Vorgabe, unter Windows 7 eben wieder VistaDelete=1, falls der Windows Papierkorb eine Bestätigung einholt.
UseTrash=1 (T.C. soll Papierkorb benutzen unverändert auf "eingeschaltet")
Bestätigungsdialog des Windows Papierkorbs abgeschaltet.
T.C. gestoppt und gestartet.
Ergebnis:
Beim Betätigen von DEL bringt der Total Commander seinen eigenen Bestätigungsdialog.
D.h. T.C. benutzt VistaDelete=0, weil der Windows Papierkorb keine Bestätigungsabfrage bringt.
Test 2 mit VistaDelete=1 in der wincmd.ini
In der wincmd.ini VistaDelete=1 wieder hinzugefügt.
UseTrash=1 (T.C. soll Papierkorb benutzen unverändert auf "eingeschaltet")
Bestätigungsdialog des Windows Papierkorbs bleibt abgeschaltet.
T.C. gestoppt und gestartet.
Ergebnis:
DEL löscht ohne Nachfrage die markierten Objekte in den Papierkorb.
D.h. explizit gesetztes VistaDelete=1 zwingt T.C., mittels VistaDelete in den Papierkorb zu löschen, obwohl der Papierkorb keine Sicherheitsabfrage zeigt.
Da ich das hier nun unter 32-bit Windows getestet habe, müßte ich das nun auch noch auf Windows 64-bit durchspielen, um deine Umgebung zu treffen ...
Grüße,
Karl
Sieht so aus, als zwinge VistaDelete=1 T.C. tatsächlich, unter Windows Vista, Windows 7, Server 2008 die VistaDelete Methode zu benutzen, obwohl die Papierkorb-Bestätigung abgeschaltet ist.
Umgebung:
Windows 7 SP1, 32-bit
Total Commander 8.0ß9 32-bit
Test 1 ohne VistaDelete in der wincmd.ini
In der wincmd.ini VistaDelete=1 entfernt, also gilt nach dem Neustart des T.C. die Vorgabe, unter Windows 7 eben wieder VistaDelete=1, falls der Windows Papierkorb eine Bestätigung einholt.
UseTrash=1 (T.C. soll Papierkorb benutzen unverändert auf "eingeschaltet")
Bestätigungsdialog des Windows Papierkorbs abgeschaltet.
T.C. gestoppt und gestartet.
Ergebnis:
Beim Betätigen von DEL bringt der Total Commander seinen eigenen Bestätigungsdialog.
D.h. T.C. benutzt VistaDelete=0, weil der Windows Papierkorb keine Bestätigungsabfrage bringt.
Test 2 mit VistaDelete=1 in der wincmd.ini
In der wincmd.ini VistaDelete=1 wieder hinzugefügt.
UseTrash=1 (T.C. soll Papierkorb benutzen unverändert auf "eingeschaltet")
Bestätigungsdialog des Windows Papierkorbs bleibt abgeschaltet.
T.C. gestoppt und gestartet.
Ergebnis:
DEL löscht ohne Nachfrage die markierten Objekte in den Papierkorb.
D.h. explizit gesetztes VistaDelete=1 zwingt T.C., mittels VistaDelete in den Papierkorb zu löschen, obwohl der Papierkorb keine Sicherheitsabfrage zeigt.
Da ich das hier nun unter 32-bit Windows getestet habe, müßte ich das nun auch noch auf Windows 64-bit durchspielen, um deine Umgebung zu treffen ...
Grüße,
Karl
Hallo, Andreas.
Deine Konfiguration müßte meinem Test #2 entsprechen. Dabei sollte T.C. 8 wegen des ausdrücklich gesetzten VistaDelete=1 und trotz fehlender Bestätigungsabfrage des Windows Papierkorbs die VistaDelete Methode verwenden. (1)
Das wiederum soll genau die Symptome verhindern, die du berichtet hast.
Also sind wir nach der kleinen Ehrenrunde wieder bei der Ausgangsfrage angelangt: Warum verhält sich T.C. 8 trotzdem so, wie er es bei dir tut?
Möglichkeit 1:
Dazu fällt mir ein, dass es eine Situation gibt, in der VistaDelete=1 stets ignoriert wird, weil das Löschen sonst gar nicht funktioniert: [TC8.0ß8]: VistaDelete=1 Prevents Elevated Delete Operation. Problem behoben in T.C. 8.0ß9, indem in der besonderen Situation nie die VistaDelete Methode verwenden wird. (Dabei könnte es also wieder zu extremer Systemauslastung kommen, wenn sehr viele Objekte, z.B. 20.000 - gelöscht werden.)
Möglichkeit 2:
T.C. 8 benutzt auch bei dir VistaDelete (1). Trotzdem kommt aus zu einer sehr viel höheren Systemauslastung als beim Löschen mittels Explorer.
Ob das passieren kann, weiß ich momentan nicht, weil ich fast nie soviele Objekte auf einen Rutsch löschen muß, jedenfalls nicht auf meinem lokalen Windows Rechner. (Und Löschen per FTP oder SFTP auf einem entfernten Unix Rechner ist, im Hinblick auf die lokale Systemlast, ein völlig anderer Vorgang.)
(1)
Ob T.C. 8 auf deinem Windows Rechner jeweils wirklich die VistaDelete Methode benutzt, kannst du einfach herausfinden: Markiere irgendeine unwichtige Datei im %TEMP% Ordner und drücke DEL.
Erscheint jetzt eine Total Commander Bestätigungsabfrage, dann verwendet T.C. 8 in dem Moment seine eigene Löschmethode.
Verschwindet die Datei ohne Rückfrage im Papierkorb, dann verwendet T.C. 8 in dem Moment die VistaDelete Methode.
Grüße,
Karl
Deine Konfiguration müßte meinem Test #2 entsprechen. Dabei sollte T.C. 8 wegen des ausdrücklich gesetzten VistaDelete=1 und trotz fehlender Bestätigungsabfrage des Windows Papierkorbs die VistaDelete Methode verwenden. (1)
Das wiederum soll genau die Symptome verhindern, die du berichtet hast.
Also sind wir nach der kleinen Ehrenrunde wieder bei der Ausgangsfrage angelangt: Warum verhält sich T.C. 8 trotzdem so, wie er es bei dir tut?
Möglichkeit 1:
Dazu fällt mir ein, dass es eine Situation gibt, in der VistaDelete=1 stets ignoriert wird, weil das Löschen sonst gar nicht funktioniert: [TC8.0ß8]: VistaDelete=1 Prevents Elevated Delete Operation. Problem behoben in T.C. 8.0ß9, indem in der besonderen Situation nie die VistaDelete Methode verwenden wird. (Dabei könnte es also wieder zu extremer Systemauslastung kommen, wenn sehr viele Objekte, z.B. 20.000 - gelöscht werden.)
Möglichkeit 2:
T.C. 8 benutzt auch bei dir VistaDelete (1). Trotzdem kommt aus zu einer sehr viel höheren Systemauslastung als beim Löschen mittels Explorer.
Ob das passieren kann, weiß ich momentan nicht, weil ich fast nie soviele Objekte auf einen Rutsch löschen muß, jedenfalls nicht auf meinem lokalen Windows Rechner. (Und Löschen per FTP oder SFTP auf einem entfernten Unix Rechner ist, im Hinblick auf die lokale Systemlast, ein völlig anderer Vorgang.)
(1)
Ob T.C. 8 auf deinem Windows Rechner jeweils wirklich die VistaDelete Methode benutzt, kannst du einfach herausfinden: Markiere irgendeine unwichtige Datei im %TEMP% Ordner und drücke DEL.
Erscheint jetzt eine Total Commander Bestätigungsabfrage, dann verwendet T.C. 8 in dem Moment seine eigene Löschmethode.
Verschwindet die Datei ohne Rückfrage im Papierkorb, dann verwendet T.C. 8 in dem Moment die VistaDelete Methode.
Grüße,
Karl
Testumgebung:
Netter Zeitvertreib mit der praktisch untermauerten Erkenntnis, dass man VistaDelete=0 auf Server 2008 R2 wirklich nicht empfehlen kann, wenn man viele Objekte in den Papierkorb befördern muß.
Mit Blick auf das eingangs berichtete Verhalten
Also tragen die berichteten Testergebnisse alle eher nichts zur Analyse und Lösung des Problems bei.
Schade.
--
Nachgetragen: gemessene Zeit für Test #4
- 2 CPU-Kerne, 2 GB RAM
- Server 2008 R2, also 64-bit
- Total Commander 8.0ß 32-bit / 64-bit (32-bit oder 64-bit spielt für die Geschwindigkeit keine Rolle!)
- Variiert:
+ Windows Papierkorb Bestätigungsdialog
+ Total Commander Parameter: VistaDelete, UseTrash - 2 Ordner auf 2 unterschiedlichen lokalen Laufwerken mit vor jedem Probelauf neu angelegten 20.000 Dateien
- Papierkorbbestätigung=ein
- VistaDelete=1, UseTrash=1
- Explorer:
20000 Dateien markiert und DEL gedrückt.
Verschieben in den Papierkorb bestätigt.
Zeit zum Löschen in den Papierkorb: 2,5 Min.
Private Bytes: max. 220 MB.
CPU Last: 75% (über beide Kerne) - Total Commander 8.0 beta:
20000 Dateien markiert und DEL gedrückt.
Verschieben in den Papierkorb bestätigt.
Zeit zum Löschen in den Papierkorb: 3,25 Min.
Private Bytes: max. 264 MB.
CPU Last: 50% (über beide Kerne)
wobei man beachten muß, dass VistaDelete bewirkt, dass der Explorer ebenfalls RAM beim Löschen verbraucht und CPU-Zeit, ungefähr so viel wie der T.C.
- Papierkorbbestätigung=aus
- VistaDelete=1, UseTrash=1
- Explorer:
20000 Dateien markiert und DEL gedrückt.
Verschieben in den Papierkorb bestätigt.
Zeit zum Löschen in den Papierkorb: 3,0 Min. - Total Commander 8.0 beta:
20000 Dateien markiert und DEL gedrückt.
Verschieben in den Papierkorb bestätigt.
Zeit zum Löschen in den Papierkorb: 2,5 Min. - Die Fast-Umkehr der Löschzeiten ist bedingt dadurch, dass Explorer auf dem Laufwerk des T.C. aus Test #1 und T.C. auf dem Laufwerk des Explorers aus Test #1 löschen mußte.
- Papierkorbbestätigung=aus
- VistaDelete entfernt, UseTrash=0
- Total Commander 8.0 beta:
20000 Dateien markiert und DEL gedrückt.
Direktes Löschen bestätigt.
Zeit zum endgültigen Löschen: 0,5 Min. (37 Sek.) - Private Bytes: (unauffällig)
- CPU-Last: (gering)
- Papierkorbbestätigung=aus
- VistaDelete entfernt, UseTrash=1
- Total Commander 8.0 beta:
20000 Dateien markiert und DEL gedrückt.
Verschieben in den Papierkorb bestätigt.
Zeit zum Verschieben in den Papierkorb: 1 Std 45 bis 2 Std (geschätzt)
Zeit zum Verschieben in den Papierkorb: 2 Std 46 Min. (gemessen) - Private Bytes: 64 MB (langsam steigend?) - 76 MB (am Ende)
- CPU-Last: um 90% (über 2 Kerne), Gesamtlast des Systems: 2x100% permanent
- Der Verschiebevorgang startet langsam und wird anscheinend immer langsamer. Darum mußte die geschätzte Dauer im Laufe der letzten Stunde von 30 Min. auf 60 Min auf 90 Min und mittlerweile auf eher 120 Min. korrigiert werden.
Der Status z.Z.: 67% fertig
Ob jemals 100% erreicht werden?
Oder sinkt das Tempo irgendwann auf 0?
Netter Zeitvertreib mit der praktisch untermauerten Erkenntnis, dass man VistaDelete=0 auf Server 2008 R2 wirklich nicht empfehlen kann, wenn man viele Objekte in den Papierkorb befördern muß.
Mit Blick auf das eingangs berichtete Verhalten
so konnte dieses jedoch bisher nicht reproduziert werden.Andreas wrote:Ist mit dem TC unmöglich. RAM-Verbrauch jagt auf 1,3 GB hoch, CPU Last steigt und kurz darauf friert das Programm ein
Also tragen die berichteten Testergebnisse alle eher nichts zur Analyse und Lösung des Problems bei.
Schade.
--
Nachgetragen: gemessene Zeit für Test #4
Last edited by karlchen on 2011-11-19, 19:44 UTC, edited 1 time in total.
Habe gestern ein Beweisfoto gemacht als der RAM und CPU so langsam aber sicher merklich zunahmen 
http://imageshack.us/photo/my-images/43/2011111900.gif/
http://imageshack.us/photo/my-images/43/2011111900.gif/
Gruß Andreas
Win10 x64 +++ Total Commander 10 +++ Directory Opus 12 +++
Win10 x64 +++ Total Commander 10 +++ Directory Opus 12 +++
Ich glaub's ja. 
Konnte es eben nur noch nicht reproduzieren.
Den höchsten RAM-Verbrauch mit knapp 1 GB Private Bytes habe ich bisher gesehen, als der Explorer 2 x 20000 gelöschte Dateien aus dem Papierkorb endgültig ins Datennirwana befördern mußte. Hat so ca. 6 Min. gebraucht. Aber auch dabei kein Systemstillstand.
Karl
Konnte es eben nur noch nicht reproduzieren.Den höchsten RAM-Verbrauch mit knapp 1 GB Private Bytes habe ich bisher gesehen, als der Explorer 2 x 20000 gelöschte Dateien aus dem Papierkorb endgültig ins Datennirwana befördern mußte. Hat so ca. 6 Min. gebraucht. Aber auch dabei kein Systemstillstand.
Karl
-
ghisler(Author)
- Site Admin
- Posts: 50639
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
VistaDelete geht leider nicht bei Suchergebnissen, Strg+B oder Synchronisieren. Die Funktion von Windows hat einen Bug - übergibt man ihr Dateien aus verschiedenen Verzeichnissen, dann löscht sie diese Verzeichnisse komplett, und nicht nur die angegebenen Dateien. TC muss deshalb alle Dateien einzeln in den Papierkorb löschen. Leider erzeugt Windows dann für jede Datei einen eigenen Löschthread, was enorm viel Speicher kostet.
Die einzige Lösung ist, die Dateien halt direkt zu löschen (Umschalttaste gedrückt halten), oder in ein gemeinsames Verzeichnis zu verschieben und danach zu löschen.
Die einzige Lösung ist, die Dateien halt direkt zu löschen (Umschalttaste gedrückt halten), oder in ein gemeinsames Verzeichnis zu verschieben und danach zu löschen.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com