Bis ich da eine Lösung gefunden habe, können Sie das Reagieren auf WM_DEVICECHANGE deaktivieren:
Wincmd.ini
Abschnitt [Configuration]
DeviceChange=0
Tabs verlieren Laufwerk / Verzeichnis
Moderators: white, Hacker, Stefan2
-
ghisler(Author)
- Site Admin
- Posts: 48083
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Sieht sehr gut aus!
Mit der Konfigurationsänderung DeviceChange=0 können wir gut leben.
Ohne die Einstellung ist der Fehler bei mehreren PCs reproduzierbar (USB Stick einstecken -> Laufwerk springt auf C: um). Mit dem DeviceChange=0 bleiben die Laufwerke auf M: stehen wie sie sollen.
Ob diese Einstellung noch andere Auswirkungen hat, können wir noch nicht sagen.
Aber die Ursache des Problems wird genau in dem Verhalten des TC bei den DeviceChange Events liegen.
Mit der Konfigurationsänderung DeviceChange=0 können wir gut leben.
Ohne die Einstellung ist der Fehler bei mehreren PCs reproduzierbar (USB Stick einstecken -> Laufwerk springt auf C: um). Mit dem DeviceChange=0 bleiben die Laufwerke auf M: stehen wie sie sollen.
Ob diese Einstellung noch andere Auswirkungen hat, können wir noch nicht sagen.
Aber die Ursache des Problems wird genau in dem Verhalten des TC bei den DeviceChange Events liegen.
Insgesamt sind meine Anwender eigentlich sehr glücklich mit dem aktuellen Stand.
Das jetzt bei DeviceChange kein automatisches Refresh der Anzeige mehr kommt ist zu verschmerzen.
Wenn da für eine richtige Lösung kommt, so das wir das DeviceChance wieder aktivieren können, wäre das natürlich super.
Insgesamt vielen Dank an Herrn Ghisler für seinen Einsatz und die Problemlösung.
Das jetzt bei DeviceChange kein automatisches Refresh der Anzeige mehr kommt ist zu verschmerzen.
Wenn da für eine richtige Lösung kommt, so das wir das DeviceChance wieder aktivieren können, wäre das natürlich super.
Insgesamt vielen Dank an Herrn Ghisler für seinen Einsatz und die Problemlösung.
Wir haben wieder Umstände entdeckt, die zum Wechsel der Tabs vom Netzwerklaufwerk auf C: führen (mit der totalcmd.exe 8.52b1 vom 24.9.2015).
Die Fehler sind bei uns reproduzierbar und ich habe sogar einige Videos aufzeichnen können.
1. Beim Öffnen einer Dateieigenschaft per Rechts-klick/Eigenschaften springt auf der linken Seite der aktuelle Tab auf C: zurück. Merkwürdigerweise NICHT, wenn mittels Alt-Eingabe die Dateieigenschaften geöffnet werden.
2. Beim Starten mancher externer Applikation (hier: Öffnen einer .ico Datei mit einem Iconmanager) springt die linke Seite im Hintergrund auf C: um.
Die Fehler sind bei uns reproduzierbar und ich habe sogar einige Videos aufzeichnen können.
1. Beim Öffnen einer Dateieigenschaft per Rechts-klick/Eigenschaften springt auf der linken Seite der aktuelle Tab auf C: zurück. Merkwürdigerweise NICHT, wenn mittels Alt-Eingabe die Dateieigenschaften geöffnet werden.
2. Beim Starten mancher externer Applikation (hier: Öffnen einer .ico Datei mit einem Iconmanager) springt die linke Seite im Hintergrund auf C: um.
-
ghisler(Author)
- Site Admin
- Posts: 48083
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Sie können das automatische Neu-Einlesen beim Wechsel zum Total Commander deaktivieren:
Konfigurieren - Einstellungen - Neu Einlesen
Kein Neu-Einlesen: \
(Backslash eintragen = UNC-Pfade nicht neu Einlesen).
Konfigurieren - Einstellungen - Neu Einlesen
Kein Neu-Einlesen: \
(Backslash eintragen = UNC-Pfade nicht neu Einlesen).
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Hallo Herr Ghisler,
ich war etwas über eine Woche nicht im Hause, deshalb hat es etwas gedauert.
Wir haben die Einstellung mal geprüft, es hat leider keine Verbesserung gebracht.
Ein Anwender ist auf noch eine Stelle gestoßen (das Kurzvideo sende ich Ihnen direkt zu), bei der es sogar eine Fehlermeldung "Zugriff auf Zieldatei m:\" gibt. Dieser Fehler ist sogar an allen getesteten Plätzen wiederholbar. Merkwürdigerweise tritt der Fehler _NICHT_ auf, wenn man direkt auf "\" klickt.
Falls hilfreich kann ich noch mal einen Trace mit dem ProcessMonitor anfertigen.
Insgesamt haben wir noch beobachtet:
-Es betrifft NUR unser Laufwerk M:. Diese Share liegt auf einer EMC VNX 5400; andere Shares des gleichen Servers sind davon nicht betroffen. Ich versuche festzustellen, welche Einstellung oder Eigenschaft dieses unterschiedliche Verhalten der Shares verursachen könnte
-Dieser in dieser Mail beschriebene Fehler tritt nur auf, wenn ein Standard-User benutzt wird; wird ein Benutzer mit vollen Berechtigungen auf die Share verwendet, so funktioniert es
Insgesamt drehen wir uns hier aber wohl immer um das selbe Problem im TC: Detektierung/Refresh des aktuellen Laufwerks
ich war etwas über eine Woche nicht im Hause, deshalb hat es etwas gedauert.
Wir haben die Einstellung mal geprüft, es hat leider keine Verbesserung gebracht.
Ein Anwender ist auf noch eine Stelle gestoßen (das Kurzvideo sende ich Ihnen direkt zu), bei der es sogar eine Fehlermeldung "Zugriff auf Zieldatei m:\" gibt. Dieser Fehler ist sogar an allen getesteten Plätzen wiederholbar. Merkwürdigerweise tritt der Fehler _NICHT_ auf, wenn man direkt auf "\" klickt.
Falls hilfreich kann ich noch mal einen Trace mit dem ProcessMonitor anfertigen.
Insgesamt haben wir noch beobachtet:
-Es betrifft NUR unser Laufwerk M:. Diese Share liegt auf einer EMC VNX 5400; andere Shares des gleichen Servers sind davon nicht betroffen. Ich versuche festzustellen, welche Einstellung oder Eigenschaft dieses unterschiedliche Verhalten der Shares verursachen könnte
-Dieser in dieser Mail beschriebene Fehler tritt nur auf, wenn ein Standard-User benutzt wird; wird ein Benutzer mit vollen Berechtigungen auf die Share verwendet, so funktioniert es
Insgesamt drehen wir uns hier aber wohl immer um das selbe Problem im TC: Detektierung/Refresh des aktuellen Laufwerks
Last edited by BOst on 2016-05-13, 09:53 UTC, edited 1 time in total.
Vielleicht haben wir die Lösung/Ursache für ALLE hier in diesem Thread benannten Probleme gefunden:
Wir setzen für den Share M: das Flag "accessbasedenum" ein, d.h. es werden den Anwendern nur die Verzeichnisse angezeigt, für die er auch Rechte besitzt.
Setzen wir jetzt auf das Root-_Verzeichnis_ der Share, OHNE Vererbung die "Traverse Folder/execute File" Permission auf "allow", so scheinen alle Probleme gelöst. Die Tests sehen jedenfalls gut aus.
https://technet.microsoft.com/en-us/library/cc787794(v=ws.10).aspx
Wir setzen für den Share M: das Flag "accessbasedenum" ein, d.h. es werden den Anwendern nur die Verzeichnisse angezeigt, für die er auch Rechte besitzt.
Setzen wir jetzt auf das Root-_Verzeichnis_ der Share, OHNE Vererbung die "Traverse Folder/execute File" Permission auf "allow", so scheinen alle Probleme gelöst. Die Tests sehen jedenfalls gut aus.
https://technet.microsoft.com/en-us/library/cc787794(v=ws.10).aspx