Recover Undelete

[karlchen]

Hi an alle.

Die Frage ist doch, in wie weit will, kann und muss man den User vor seiner eigenen Dummheit schützen.

Kann man nicht. - Wer wild entschlossen ist, sich über die Klippe zu stürzen, oder einfach auch nur schusselig genug, ständig über die eigenen Füße zu stolpern, der wird genau das auch weiterhin tun.

Und wie gesagt, die Kombination "Shift+Enf", Enter und JA Button aktiv halte ich für etwas "unglücklich".
Das wäre wirklich das einzige (NEIN aktiv), was man ändern könnte und sollte.

Damit kann ich mich ausdrücklich anfreunden. Bei jeder destruktiven Aktion, macht es Sinn, den Nein oder Abrechen Button als Default-Button zusetzen.
Ebenfalls kann ich mich sehr wohl mit der Idee / der Anforderung identifizieren, die ziemlich am Anfang des Threads vorgebracht worden ist, dass die Bestätigigungsmeldungen vor dem Löschen in den Papierkorb und vor dem endgültigen Löschen unter Umgehung des Papierkorbs sich optisch deutlich unterscheiden sollten.

Vielleicht kann Christian wirklich nicht zuverlässig feststellen, ob T.C. bei DEL/F8 in den Papierkorb verschiebt. Dann laßt die Meldung so wie sie jetzt ist.

Aber wann beim Löschen zusätzlich die Shift-Taste gedrückt worden ist, das weiß T.C. sehr wohl. Also kann zumindest in diesem Fall die Meldung

Soll die markierte Datei abcde.fgh wirklich gelöscht werden?

Sollen die 99 markierten Dateien/Verzeichnisse wirklich gelöscht werden?

umgestaltet werden in

Soll die markierte Datei abcde.fgh wirklich endgültig gelöscht werden?

Sollen die 99 markierten Dateien/Verzeichnisse wirklich endgültig gelöscht werden?

Meine Idee mit den Eingabefeld vielleicht als Option, alles andere wäre zu viel.

Noch ein zusätzliches Bestätigungsfeld ist zuviel. Dem geht es genau wie der ständigen UAC Abfrage im Vista: Es kursieren Tipps, wie auch die blutigsten Anfänger sie abstellen können. Und andere entwickeln ein fatales Talent jeden UAC Dialog zu bestätigen, ohne auch nur einen einzigen gelesen zu haben.

Wenn ihr den Löschvorgang in dem fehlgeleiteten Fürsorglichkeitswahn, Leichtsinnsvögel vor ihrer eigenen Nachlässigkeit schützen zu müssen oder auch nur zu können, verkompliziert, dann erreicht ihr nur, dass noch mehr Benutzer als bereits heute sämtliche sinnvollen Sicherheitsabfragen abschalten. (Im schlimmsten Fall erledigt man sowas dann mit AHK.)

Abgesehen von seinem Fehlgriff mit einem weiteren Eingabefeld zur Löschbestätigung stimme ich mit "Herrn Mann's" Position durchaus überein.

Grüße,
Karl

[HolgerK]

Kann man nicht. - Wer wild entschlossen ist, sich über die Klippe zu stürzen, oder einfach auch nur schusselig genug, ständig über die eigenen Füße zu stolpern, der wird genau das auch weiterhin tun.

Das Problem ist doch, das dem Unaufmerksamen nur unzureichende Hinweise vorliegen, dass er grade versuchen will zu fliegen.
War's in diesem Thead (oder in einem entsprechende Thread des englischen Forums), wo genau mit diesem Beispiel darauf hingewiesen wurde, das die Beschilderung der Klippe einfach unzureichend ist?

Damit kann ich mich ausdrücklich anfreunden. Bei jeder destruktiven Aktion, macht es Sinn, den Nein oder Abrechen Button als Default-Button zusetzen.

Da gab's auch schon das Gegenargument:
Dann gewöhnt man sich schnell an den Shortcut des Buttons <J> anstelle von <Eingabe> zu benutzen.
Letztendlich ändert das dann nichts wesentliches an der Sicherheit.
Andere Überlegung:
Wenn ich schnell (endgültig) löschen will und analog zu <Entf><Eingabe> dann gewohnheitsmäßig <UMSCH+Entf><Eingabe> drücke, kriege ich evtl. gar nicht mit, das die Dateien nicht gelöscht wurden!

Aber wann beim Löschen zusätzlich die Shift-Taste gedrückt worden ist, das weiß T.C. sehr wohl

Er weiß das sogar so gut, dass ein <Umsch+Entf> bei ausgeschalteter Option "[ ] F8/Entf löscht in den Papierkorb (UMSCH=direkt)" in den Papierkorb verschiebt!

Ob die textuelle Umgestaltung der Meldung alleine etwas bringt, bezweifel ich.
Das war in diesem fall ja auch nicht der Fall (500 anstelle von 1 Datei!).

Wenn ihr den Löschvorgang in dem fehlgeleiteten Fürsorglichkeitswahn, Leichtsinnsvögel vor ihrer eigenen Nachlässigkeit schützen zu müssen oder auch nur zu können, verkompliziert, dann erreicht ihr nur, dass noch mehr Benutzer als bereits heute sämtliche sinnvollen Sicherheitsabfragen abschalten.

Ich hatte den Sinn und Zweck diese Threads eher darin gesehen etwas dezent zu ändern und nicht zu verkomplizieren.
Ziel sollte sein, dem Anwender deutlicher zu mache auf welche Daten evtl. ungewollt eine Aktion ausgeführt werden.

Eine einfache Umgestaltung einer Textbox, die sowieso nicht gelesen wird, ist da imho nicht ausreichend.
Damit kann man nur im Anschluss sagen "selber Schuld", ohne den gelegentlichen Fehlgriff zu vermeiden.

Mag sein, dass einige meiner Ideen dann über das Ziel etwas hinausgegangen sind.
Aber wie bereits mehrfach gesagt: Optional!

Gruß,
Holger

[Hacker]

Auch von mir an alle
Es geht nicht um die eigentliche Aktion "Loeschen", sondern um was man loescht. Utnapischtim wollte loeschen, nur halt nicht was markiert war, sondern was unterm Cursor stand. Deshalb sollte es auch nicht das Ziel sein, das eigentliche Loeschen zu erschweren. Wie man aber besser hervorhebt, dass nicht die Datei unterm Cursor sondern die markierten Dateien die Quelle der Operation sind, weiss ich leider nicht.
- das "Show only selected" vor der Dateioperation wuerde niemanden vor der Del-Enter Kombination retten, der nicht schon von der Dateiliste in der Bestaetigungsabfrage gestoppt wird
- ein DingDong wenn der Cursor auf einer Datei ist, die nicht markiert ist, wuerde sich einer nach 5 Minuten abgewoehnen zu beachten, wenn er ueblicherweise Dateien per Insert markiert

Traurig aber wahr ist, dass man erst nach einem richtigen Datenverlust anfaengt, vor dem Del-Enter nochmals die Markierung zu ueberpruefen.
Traurig aber wahr ist auch, dass Fehler auch so passieren und passieren werden.

Roman

[Hacker]

P.S.: Vielleicht lag der Denkfehler ja darin, dass Shift-F6 die Datei unterm Cursor umbenennt, Shift-F8 aber nicht die Datei unterm Cursor loescht.

Roman

[Dalai]

So, jetz misch ich mich nochmal ein .
Ein weiterer Vorschlag von mir: im Bestätigungsdialog eine Listbox fester Größe (scrollbar) mit den Dateinamen, die gelöscht werden sollen. Weiterhin die Anzahl der zu löschenden Dateien fett und/oder farblich hervorheben.

Auf keinen Fall will ich aber ein zusätzliches Eingabefeld (mit JA o.ä.), weil das einfach den Arbeitsfluss bremst.
Mit einem Default auf NEIN kann ich mich aber durchaus anfreunden, auch wenn ich das "Problem" sehe, dass man sich dann schnell an Umsch+Entf -> Cursor links -> Enter oder ähnliches gewöhnt.

Ansonsten kann ich nur sagen: gut, wenn man ein funktionierendes Backup hat. Und das trifft nicht nur auf Daten sondern auch auf's OS zu, nicht nur in diesem Fall.

MfG Dalai

[Herr Mann]

Ein weiterer Vorschlag von mir: im Bestätigungsdialog eine Listbox fester Größe (scrollbar) mit den Dateinamen, die gelöscht werden sollen.

Keine schlechte Idee, da ja nur die ersten 5 Dateien angezeigt werden.
Aber wer guckt da genau hin und scrollt durch?
Hilft das wirklich gegen das versehentliche Löschen?

Ursprünglich ging es ja wohl darum, das Utnapischtim nicht bewusst war, das noch Dateien markiert waren, als es die unterm Cursor löschen wollte.
Ob das nun irgendwie "unlogisch" ist weiß ich nicht, darüber habe ich noch nie nachgedacht.
Fakt ist aber auch, das er die Dialogbox nicht richtig gelesen/beachtet hat!
Ich mache das eigentlich auch nicht. Shift+Enf, Enter ... weg sind sie.

Wie kann man sowas verhindern?
Meine Idee war ja, dem User durch die Eingabe der Dateienanzahl klar zu machen das hier viele Dateien gelöscht werden.
Man wird doch sicher stutzig, wenn man die Datei unterm Cursor löschen wollte, der TC einem aber so unmissverständlich auffordert 500 Dateien zu bestätigen.
Klar, das hindert den Arbeitsfluss und das ich hierfür nicht gerade Applaus bekomme versteh ich.
Ich wollte mit meiner Idee ja auch nur verhindern, das der User zuschnell ohne zu lesen (und nachzudenken) Enter drückt.

gut, wenn man ein funktionierendes Backup hat

Richtig. Nur leider sind Backups nicht synchron. Sie sind also oft Stunden oder sogar Tage alt. Wenn man Pech, ist trotz regelmäßiger Sicherung der aktuelle Tag weg.

[Lefteous]

Beispiel: 5000 Datei in der Ansicht; 10 Dateien im ersten Drittel der Liste sind markiert, der Cursor befindet sich grade auf Datei 4223.
-> Muss ich dann mit dem Cursor zur ersten markierten Datei springen, um nur die markierten Dateien zu löschen?

Mir ist völlig bewusst, dass das natürlich eine große Umstellung in der Bedienung des Programms wäre. Statt den Cursor arglos in der Gegend herum stehen zu lassen, wird man durch diesen Ansatz dazu bewegt zurück zur Markierung zu navigieren.
Es ist immer ein Tradeoff und man muss Prioritäten setzen. Entscheidet man sich für meinen Vorschlag setzt man Sicherheit vor Effizienz.

Davon abgesehen hat hier mit Sicherheit keine der am dem Kernproblem angreifenden Ideen wirklich eine Chance auf Umsetzung. Das liegt einfach an der Legacy des Programms. Das meine ich gar nicht mal technisch, sondern vielmehr in der Benutzerschnittstelle. Solche gravierenden Einschnitte machen nur zu frühen Phasen eines Programmes Sinn. Der Total Commander wird aber dieses Jahr 15 Jahre alt. Das Programm ist wie es ist. Man kann noch Kleinigkeiten verbessern und ein paar Anbauten vornehmen, aber im Grunde war es das.

[algol]

Es ist immer ein Tradeoff und man muss Prioritäten setzen. Entscheidet man sich für meinen Vorschlag setzt man Sicherheit vor Effizienz.

Wenn Sicherheit>Effizienz, dann "please, count me out" - denn ich bin begeisterter TC-user, und das _ausschliesslich_ wegen seiner unüberbotenen Effizienz.

Das "Rausscroll"-Argument verstehe ich jedoch. Und ich denke mal, Christian auch.

Daher begrüsse ich ausdrücklich "karlchen's" Vorschlag mit dem modifizierten Meldungsfenster mit "99" und "endgültig" in fett und rot. Denn auch hier gilt: "Wer lesen kann, ist klar im Vorteil!" - Und wer's dennoch nicht tut - eben nicht!

Weiters sollte der Cursor auf die inverse Selektionsfarbe bzw. dunkelrot o. ä. umschalten, sobald Dateien ausserhalb des Cursors - oder gar des Sichtfensters - markiert sind.

Darüberhinaus wäre äusserstenfalls ein genereller Löschsperrmodus für Dillettanten und "Zauberlehrlinge" vorstellbar - aber bitte verschont uns Power-user mit derlei Unfug. Basta!

Da halte ich es ebenfalls ganz mit "karlchen":

[face=comicsansms]HilfÄÄ! HilfÄÄ![/face]

Eine Horde unverbesserlicher Weltverbesserer, die meinen, sie könnten und müßten mich mit bürokratischen Tricks vor meiner eigenen Unvorsichtigkeit schützen.

[face=comicsansms]HilfÄÄ! HilfÄÄ![/face]

Wer schützt mich jetzt vor denen???

greetings
Gerald

[algol]

Weiters sollte der Cursor auf die inverse Selektionsfarbe bzw. dunkelrot o. ä. umschalten, sobald Dateien ausserhalb des Cursors - oder gar des Sichtfensters - markiert sind.

Zugegeben, sich selbst zu quoten ist kein besonders guter Stil, aber wie ich inzwischen gesehen habe, bedarf das obige statement der Präzisierung, denn in den color-options gibt es "inverted cursor" und "inverted selection". Gemeint war aber:

Sobald Dateien ausserhalb des Cursors - oder gar des Sichtfensters - markiert sind, sollte der Cursor auf die komplementäre Selektionsfarbe mit Farbsaum in der Selektionsfarbe - oder eben z.B. dunkelrot umschalten - während z.B. ich für den Standard-Cursor "inverted cursor" in einer anderen (milderen) Kontrastfarbe benutze.

Eine veränderte Cursorfarbe bei aktiver Markierung wäre, wie ich meine, ein deutliches Indiz für all jene, die zumindest hinsehen, dass die kommende Operation sich nicht bzw. nicht nur auf die Datei unter dem Cursor beziehen wird, sondern eben auf die mit der geänderten Cursorfarbe in farblichem Zusammenhang stehende Markierung.

Denen, die sowieso nicht hinsehen, kann und sollte m.E. nicht - und schon gar nicht auf Kosten der Effizienz - geholfen werden.

greetings
Gerald

[Franz Müller]

Bevor ich den TC unter Windows kennenlernte, verwendete ich unter MS-Dos das Tool XTree-Pro, ein für damalige Zeiten hervorragender Dateimanager.

Die Unterscheidung, eine oder alle markierten Dateien zu bearbeiten, war dort meines Erahtens besser gelöst als im TC: Der Befehl zum Löschen, kopieren, Verschieben etc. einer Datei, nämlich der Datei unter dem Cursor, war ein Eintastenbefehl, wollte man dieselbe Funktion für alle markierten Dateien aufrufen, mußte man zusätzlich strg drücken.

[dumbledore954]

Der Befehl zum Löschen, kopieren, Verschieben etc. einer Datei, nämlich der Datei unter dem Cursor, war ein Eintastenbefehl, wollte man dieselbe Funktion für alle markierten Dateien aufrufen, mußte man zusätzlich strg drücken

Na, das klingt doch sehr interessant, zumal sich ja markierte Dateien oder Ordner gerne mal außerhalb des sichbaren Bereichs befinden, z. B. als Überbleibsel eines Vergleichs ...

[Lefteous]

Na, das klingt doch sehr interessant, zumal sich ja markierte Dateien oder Ordner gerne mal außerhalb des sichbaren Bereichs befinden, z. B. als Überbleibsel eines Vergleichs ...

Wo ist da jetzt der Zusammenhang? Das Drücken einer zusätzlichen macht die außerhalb des sichtbaren Bereichs befindlichen Markierungen auch nicht sichtbar.

[StatusQuo]

Der Befehl zum Löschen, kopieren, Verschieben etc. einer Datei, nämlich der Datei unter dem Cursor, war ein Eintastenbefehl, wollte man dieselbe Funktion für alle markierten Dateien aufrufen, mußte man zusätzlich strg drücken.

Auf den ersten Blick eine gute Idee: (Shift+)Del löscht die Datei unter dem Cursor, erst (Shift+)Ctrl+Del löscht die markierten Dateien -
keine Gefahr mehr für die markierten Dateien ohne explizit gedrückte Ctrl-Taste.
Dabei entsteht allerdings erhöhte Gefahr für die Datei unter dem Cursor
(Insert, Delete löscht dann diese statt der markierten Dateien).

Immerhin könnte TC so leichter ein Versehen identifizieren und mit zusätzlicher Bestätigungspflicht ahnden.
Ob mir die Umgewöhnung gefallen würde? Aktuell eher nicht:
Löschen vernichtet nun mal Daten, speziell die direkte Löschfunktion sollte man also entsprechend vorsichtig anwenden.

Einfacher wäre es, die direkte Löschfunktion optional und standardmäßig abzuschalten, damit wäre TC sogar sicherer als der Explorer.