Sehr langes Warten bei nicht existentem Netzlaufwerk

[wm0001]

Zu Hause betreibe ich einen Rechner per LAN und einen anderen drahtlos am WLAN-Router (beide mit XP SP3 und allen gestern veröffentlichten Updates); jeweils ein Ordner eines Rechners ist für den anderen freigegeben. Beim mobilen Rechner ist im TC die Netzlaufwerkverbindung eingetragen. Wenn ich nun den TC auf dem mobilen Rechner starten will, während der andere Rechner abgeschaltet ist, drängt sich TC in den Vordergrund und rührt sich nicht mehr. Im Taskmanager ist die Anwendung nicht zu sehen und wenn ich es nach über einer Minute schaffe, daß eine Reaktion auf "Alt F4" erfolgt, dauert es wieder sehr lang, bis TC endlich abgewürgt wird. Anscheinend müht sich das Programm ab, die Verbindung zum abgeschalteten Rechner zustande zu bringen; kann man hierfür eine Zeit vorgeben, nach der dieser fruchtlose Versuch beendet wird?

[raeubi]

Willkommen im Forum!
Welche TC Version?

Das Thema kommt hier immer wieder mal hoch.
Hier einige Fundstellen mit Lösungen:
Andere Computer im Netzwerk (Ursache war ein DNS Problem)
Freigabe macht Probleme (Lösungsansatz durch Registy Tuning)
Netzwerk langsam (siehe Post von HolgerK, Punkt 4., Der TC bietet eine eingebaute Möglichkeit um das Warten auf langsame Verbindungen abzubrechen.)

Hilft davon etwas?

[wm0001]

Danke für die schnelle Reaktion; die Hinweise werde ich ausprobieren, wenn ich wieder zu Hause bin.

[wm0001]

So, jetzt ist es geglückt: Mit "Noreread:\" in der Einstellungsdatei startet der TC schnell wie immer. Erst wenn ich versuche die Netzwerkumgebung anzeigen zu lassen, friert er wieder ein; aber das muß man ja nicht provozieren wenn man weiß, daß ein Netzlaufwerk nicht existiert. Merkwürdig finde ich allerdings, daß im umgekehrten Fall (mobiler Rechner ist abgeschaltet und auf dem stationären per LAN mit dem Router verbundenen Rechner wird TC gestartet) diese Zicken nicht auftreten, obwohl es dort kein "Noreread:\" gibt.
Danke für die Ratschläge!

Die Version war übrigens 7.02a, ich habe jetzt auf 7.04a aktualisiert.

[ghisler(Author)]

Das Problem tritt normalerweise nur auf Rechnern auf, wo das TCP/IP-Protokoll an mehere Netzwerkinterfaces gebunden ist, z.B. an ein DSL-Modem direkt sowie an die eigentliche Dialup-Verbindung. Windows versucht dann, über beide Verbindungen zu verbinden, und merkt erst nach einem langen Timeout, dass eine davon gar nicht geht. Auf dem stationären ist wohl keine solche tote Bindung definiert.

[MC]

Sorry, aber ich habe trotzdem kein Verständnis dafür wenn ein Programm wegen was auch immer unbenutzbar tot in der Luft hängt. Es müsste trotzdem möglich sein das zumindest auf TC-Ebene abzubrechen. Soll Windows doch 3 Stunden suchen - der TC muss benutzbar bleiben.

Dass das prinzipiell gehen muss lässt sich einfach beweisen: ich kann problemlos einen zweiten TC starten und mit dem weiterarbeiten während der erste noch Kaffeepause macht...

[HolgerK]

2MC

ThreadFindFirst=1 Wenn auf 1 gesetzt wird die Funktion FindFirstFile im Hintergrund ausgeführt, so dass man das Einlesen von Verzeichnissen bei einer hängenden Netzwerkverbindung abbrechen kann.

Im TC7.50 übrigens default auf 1 gestellt.

NetHoodInThread=1 Lade Netzwerkumgebung in Hintergrundthread

Ist bereits default 1.

Hilft das nicht?

Gruß
Holger

[MC]

War mit nicht bekannt, danke für die Info. [ mecker on] Trotzdem mir unbegreiflich dass es bis zur 7.5 für sowas gebraucht hat. [mecker off]

[algol]

ThreadFindFirst=1 Wenn auf 1 gesetzt wird die Funktion FindFirstFile im Hintergrund ausgeführt, so dass man das Einlesen von Verzeichnissen bei einer hängenden Netzwerkverbindung abbrechen kann.

Im TC7.50 übrigens default auf 1 gestellt.

NetHoodInThread=1 Lade Netzwerkumgebung in Hintergrundthread

Ist bereits default 1.

Hilft das nicht?

Nicht, dass ich diesbezügliche Probleme gehabt hätte...

Ist aber eine interessante info, und so hab ich gleich meine Einstellungen gecheckt. Habe auf meinem Zweitrechner noch 7.04a als Produktionsversion und nebenher einen clean_install von 7.50rc1 zu Testzwecken parallel laufen, während das Hauptsystem schon upgrade_install 7.50rc1 fährt (ja, ich weiss, aber wer TC kennt, traut sich das ab einem rc ohne mit der Wimper zu zucken).

Und die Moral der Geschichte: Nirgends, auch nicht bei der neu erzeugten .ini aus dem clean install, kann ich die besagten Einträge finden. Netzlaufwerke gibt es aber wechselseitig.

Heisst das jetzt, erst im künftigen TC7.50 (official release) wird das so sein, oder hast Du das doch händisch in die .ini eingetragen?

mfg
algol

[HolgerK]

Heisst das jetzt, erst im künftigen TC7.50 (official release) wird das so sein, oder hast Du das doch händisch in die .ini eingetragen?

Nun, den habe ich irgendwann mal zu TC7.0-Zeiten in der wincmd.ini eingetragen.

24.10.06 Release Total Commander 7.0a14 (alpha test version 14)
..
18.10.06 Added: Experimental: wincmd.ini [Configuration] ThreadFindFirst=1 moves FindFirstFile to separate thread, so the user can abort reading from a hanging network connection

Wenn ein Eintrag ind der Wincmd.ini nicht existiert, dann wird beim Starten automatisch der Defaultwert angenommen.
Wenn eine Einstellung bereits auf dem Defaultwert stand, dann wird sie beim Speichern der Einstellungen aber auch nicht explizit erzeugt!

Die Defaultwerte sind in der Hilfe unter:

4. Konfiguration und Parameter
b. Einstellungen: wincmd.ini und wcx_ftp.ini (für FTP)

in der linken Spalte hinter dem = Zeichen angegeben.

Im Fall von ThreadFindFirst im TC7.04a muss also

Code: Select all

ThreadFindFirst=1

unter [Configuration] in der Wincmd.ini eingetragen werden.

Für den TC7.5 muss dieser Eintrag nicht vorgenommen werden, schadet allerdings auch nichts.

28.04.09 Release Total Commander 7.50 Public Beta 2 (pre)
..
22.04.09 Added: Make ThreadFindFirst=1 the default: read directory in background, so user can abort it, e.g. if network drive inaccessible

Diejenigen, die also ein Update von TC7.04a auf TC7.50 fahren, und vorher nie etwas an diesem Schalter geändert haben, sollten also automatisch in den Genuss des abbrechbaren Netzwerk-Verzeichnis-Einlesen kommen.

Gruß
Holger

[algol]

Wenn eine Einstellung bereits auf dem Defaultwert stand, dann wird sie beim Speichern der Einstellungen aber auch nicht explizit erzeugt!

Die Defaultwerte sind in der Hilfe unter:

4. Konfiguration und Parameter
b. Einstellungen: wincmd.ini und wcx_ftp.ini (für FTP)

in der linken Spalte hinter dem = Zeichen angegeben.

Danke, obwohl mir das Konzept eines Defaultwertes im Prinzip natürlich bestens vertraut ist, war mir nicht so explizit klar, dass es sich bei den in der Hilfe nach dem "="-Zeichen angegebenen Werten auch tatsächlich um den jeweiligen Defaultwert handelt. Zumal dieser dann in der .ini-Datei ja gerade nicht explizit aufscheint, es sei denn, es wurde für die betreffende Einstellung eine abweichende Option gewählt.

Nachdem in der rechten Spalte meistens (aber nicht immer alle?) Optionen erklärt sind, hielt ich das eher für beispielhafte oder gebräuchliche Werte/Einstellungen. (Btw, sind die Defaultwerte anderswo noch ausführlicher/vollständiger dokumentiert?)

Habe das aber anhand meiner Parallelversionen sofort überprüft. Und richtig: v7.04a sagt in der Hilfe "ThreadFindFirst=0", während v7.50rc1 "ThreadFindFirst=1" angibt.

Bleibt nur die Frage: in welcher physikalischen Datei stehen dann tatsächlich alle Defaultwerte, wenn nicht in der .ini? Oder sind die etwa in der 'totalcmd.exe' "hard-gecodet"'?

mfg
algol

[HolgerK]

Nachdem in der rechten Spalte meistens (aber nicht immer alle?) Optionen erklärt sind, hielt ich das eher für beispielhafte oder gebräuchliche Werte/Einstellungen.

Nun, Defaultwerte sind i.d.R. gebräuchliche Werte.
Eigentlich sollten alle Werte aufgelistet sein, einige Werte in der INI-Datei bilden sich allerdings aus der Summe von Binärpotenzen (1,2,4,8,16,..).

(Btw, sind die Defaultwerte anderswo noch ausführlicher/vollständiger dokumentiert?)

Nicht unbedingt ausführlicher/aktueller: TCWiki:Ini-Einstellungen
Ansonsten gibt es noch Ultra TC Editors mit einem lohnenswerten Konfigurationseditor.

Bleibt nur die Frage: in welcher physikalischen Datei stehen dann tatsächlich alle Defaultwerte, wenn nicht in der .ini? Oder sind die etwa in der 'totalcmd.exe' "hard-gecodet"'?

Die sind tatsächlich in der Totalcmd.exe enthalten.
Alles andere wäre ja auch nicht unbedingt sinnvoll, oder?
Welcher Default würde genommen wenn weder ein Eintrag in der Wincmd.ini noch eine default.ini existieren würde?

Gruß
Holger

[algol]

Nun, Defaultwerte sind i.d.R. gebräuchliche Werte.

Das war durchaus ernst gemeint und kein "Pseudo-Freud", denn da gibt es wohl feine Unterschiede. Defaultwerte gehen in ihrer Bedeutung weit über eine bloss gebräuchliche Einstellung hinaus, aber das brauche ich Dir wohl nicht zu erklären.

Eigentlich sollten alle Werte aufgelistet sein, einige Werte in der INI-Datei bilden sich allerdings aus der Summe von Binärpotenzen (1,2,4,8,16,..).

Benütze ich auch mehrfach, z.B. UseIniInProgramDir= für meine Parallelversion, da gibt es "unklarere" Einstellungen.

Die sind tatsächlich in der Totalcmd.exe enthalten.
Alles andere wäre ja auch nicht unbedingt sinnvoll, oder?
Welcher Default würde genommen wenn weder ein Eintrag in der Wincmd.ini noch eine default.ini existieren würde?

Das könnte durchaus Sinn machen, diese in einer übersichtlich strukturierten, vollständigen und im Klartext einsehbaren Aufstellung bereitzuhalten, selbst wenn diese Datei dann (von Normalusern) nicht ohne weiteres zu editieren wäre. Diese Datei wäre dann allerdings unverzichtbar, aber das ist so manche .dll ja auch. Der "narrensicher_er_e" Weg ist aber wohl, im Notfall nur mit dem Hauptprogramm auszukommen.

mfg
algol

[ghisler(Author)]

In TC 7 war das eine experimentelle Einstellung, da ich nicht sicher war, ob es mit allen Dateisystemen einwandfrei funktioniert. In TC 7.5 ist es nun standardmässig aktiviert, und kleinere Probleme konnte ich während des Betatests beheben.

[HolgerK]

Defaultwerte gehen in ihrer Bedeutung weit über eine bloss gebräuchliche Einstellung hinaus

Da müsste man jetzt wissen wie viele Anwender jemals den Konfigurationsdialog aufrufen, und mehr als ein oder zwei Einstellungen ändern.
Gebräuchliche Werte hängen zudem sehr stark von persönlichen Vorlieben ab (Wat den Eenen sin Uhl', ist den Annern sin Nachtigall).
Status ist also eher, dass die von Christian als sicher bzw. sinnvoll erachteten Werte hier als Default angegeben sind.

Benütze ich auch mehrfach, z.B. UseIniInProgramDir= für meine Parallelversion, da gibt es "unklarere" Einstellungen.

Ja, "UseIniInProgramDir=4" könnte man als sinnfrei bezeichnen.

Diese Datei wäre dann allerdings unverzichtbar, aber das ist so manche .dll ja auch.

Der Programmstart würde wahrscheinlich nicht unerheblich verzögert, wenn auf langsamen Medien (Usb/Netzwerk) im Zweifelsfall aus zwei Ini-Dateien gelesen werden müsste.

Gruß
Holger