TS-Doctor startet nicht bei nicht vorhandener Netzwerk-Quelle

[dpass]

Hallo Forum,

grundsätzlich läuft der Doctor bei mir Problemlos, bis auf eine reproduzierbare Ausnahme! Ich lasse den Doctor die Aufnahme-Dateien über Netzwerk direkt vom Aufnahme-PC holen, läuft soweit ganz gut, nur wenn der Aufnahme-PC beim Start von TS-Doctor nicht an ist, dann hängt sich der Doctor mit einer Zugriffsverletzung auf, und lässt sich nur per Taskmanager beenden... Es wäre schön wenn der Doctor in solch einem Fall totzdem startet und erst beim Dateiöffnen auf die fehlende Netzwerkquelle hinweist...

so denn, ich hoffe ich habe mich verständlich ausgedrückt 
dpass

[Mam]

Ja, der Fehler ist hinlänglich bekannt, aus irgendeinem Grunde wird er allerdings als "Feature" geführt und nicht beseitigt.

Der Scheff hier hat da seine eigene Logik, die sich mir leider verschließt.

[Cypheros]

Ja, der Fehler ist hinlänglich bekannt, aus irgendeinem Grunde wird er allerdings als "Feature" geführt und nicht beseitigt.

Nöhh, ist einfach nicht reproduzierbar. Hab ein Synologie NAS, das ich an und abschalten kann wie ich will aber der TS-Doctor öffnet alle Dateien immer problemlos. Nix Fehlermeldung, nix Absturz.

[Mam]

Nöhh, ist einfach nicht reproduzierbar. Hab ein Synologie NAS, das ich an und abschalten kann wie ich will aber der TS-Doctor öffnet alle Dateien immer problemlos. Nix Fehlermeldung, nix Absturz.

Hmm, dann solltest Du vielleicht mal in Betracht ziehen, ein RICHTIGES Windows Netzwerk zu installieren, so mit RICHTIGEM Fileserver, Domänencontroller und ausgelagerten Heimatverzeichnissen?
Dann wirst Du schnell erkennen, wo der Doktor so seine kleinen Unzulänglichkeiten hat. Son olles NAS mit Samba zählt nich 
(am besten noch mit NTLM 1 "Sicherheit" (LOL!)  ). Nee das ist Spielzeuchs und nicht aussagekräftig.

[dpass]

Okay, habe ich mich falsch ausgedrückt, jetzt Richtig:Der Fehler ist bei mir reproduzierbar... 
Es sind bei mir in der Tat zwei Win7 Rechner und kein NAS...
Ist jetzt nicht das große Drama, muß ich halt sehen das der Aufnahme-Rechner läuft bevor ich den Doctor starte! Aber machmal doch zu früh gestartet, oder gar versehntlich, dann wäre es schön wenn eine brauchbare Fehlermeldung erscheint und keine die zwar ein X-Knopf zum schließen hat, der aber nicht funktioniert....

Wenn es keine anderen großen Baustellen gibt, wäre es schön wenn dieser kleine Makel beseitigt wird! 

[Cypheros]

OK, habs gefunden. Netzwerklaufwerk einrichten mit Drivemapping (z.B. Laufwerk "Z:\") auf einen anderen Windows-Rechner. Datei von Z:\ öffnen und dann den Rechner, der die Datei bereitstellt herunterfahren. Dann nochmal auf Öffnen klicken und schon hängt der TS-Doctor entweder für einige Minuten oder stürzt mit Schutzverletzung ab.

Das Problem taucht in der Routine "DirectoryExists" von Delphi beim Aufruf von GetFileAttributes auf. Hier werden von Delphi nicht alle ErrorCodes wie zum Beispiel ERROR_NETNAME_DELETED abgefangen. Allerdings kann es auch vorkommen, dass die WindowsAPI erst sehr spät (nach Minuten) zurückkommt und die Anwendung blockiert oder ganz hängen bleibt.

Habe das Setzen der "Letzten Verzeichnisse" nun aus der Programminitialisierung rausgeschmissen und führe diese nun noch beim Öffnen oder Speichern einer Datei mit einer gepatchten Routine aus. Ausserdem wird die Überprüfung nun asynchron in einem eigenen Thread ausgeführt, der nach 5 Sekunden abbricht und dann eine kurze Fehlermeldung anzeigt.

Nächste Beta sollte somit keine Probleme mehr mit "schlafenden" oder nicht mehr vorhandenen Netzwerklaufwerken haben.

[Mam]

Siehste  Wo ein Wille ist, ist auch ein Gebüsch 

Allerdings kann es auch vorkommen, dass die WindowsAPI erst sehr spät (nach Minuten) zurückkommt und die Anwendung blockiert oder ganz hängen bleibt.

Na ja, das könnte man auch programmtechnisch verhindern, ist aber zugegebenermassen recht kompliziert und in diese Tiefen wollen wir Dich gar nicht absinken lassen 
Nur so als Erklärung: NetBios (der Urahn von SMB, aber mit immer noch aktiven Genen) hatte als Grundlage das OSI Schichtenmodell, läuft aber heutzutage natürlich nur noch über TCP/IP, dem bekanntermassen einige OSI Schichten fehlen (weshalb es auch viel besser funktionierte).
Was nicht da ist, muss man irgendwie simulieren, der "geniale Grundgedanke" war, einfach Timeouts statt der benötigten Quittungen zu setzen. Und so laufen da recht viele Timer, die bei Ablauf das Paket wiederholen, fehlende Quittungen wieder einsammeln usw.
Bei "Schönwetterlage" stört das wenig, aber, wenn man so dreist ist einen Partner völlig abzuschalten, dann ist Holland echt in Not und die Timer kommen in Wallung.
Hinzu kommt, dass seit Windows 7 noch das Dual-Stack TCP eingeführt ist (oder schon mit Vista? egal, das hat ja eh niemand ernsthaft benutzt), dadurch verlängert sich die Wartezeit gleich um 100%, da er erst IPV4 und dann V6 durchschneckt, natürlich brav auf die Timeouts lauernd (man kann die Suchreihenfolge ändern, aber beim Abschalten bringt das natürlich auch keinen Vorteil).

Zu Deiner Ehrenrettung muss man allerdings unbedingt hinzufügen dass Mikrosaft dem gemeinen Anwendungsprogrammieren solche Details geschickt vorenthält, Deine API macht keinen Unterschied zwischen lokalen Dateien und Netzwerkfiles. Alle Befehle (Öffnen,Lesen/Schreiben,Schließen usw.) sind identisch.
Jedoch gibt es da noch ganz gut versteckte Options, die man geschickt einsetzen kann, um den Flow zu verbessern. Aber da ja öfters mal nach dem nächsten Update das böse Wort "not supported anymore" (oder "decap..." (vergessen :-) )) auftrat, traut man sich da nicht wirklich ran. Warum programmierten Ärger in Kauf nehmen, solange es geht?

[Cypheros]

Seltsam ist nur, dass es bei Samba-Shares von Linux-Receivern oder NAS-Dosen diese Problem nicht in diesem Maße gibt. Klar muss man da manchmal auch etwas warten bis man die Antwort kriegt, dass es nicht geht aber das ist nichts im Vergleich zu reinen Windows-Netzwerken.

[Mam]

Nein, ist es nicht. Wenn ich mal wider anner richtigen Tastatur sitze, kann ich das mal erläutern, wenn Du willst.

[dpass]

Schönen Dank, ich melde mich wenns geht, und wenn nicht dann melde ich mich auch 

[Cypheros]

Nein, ist es nicht. Wenn ich mal wider anner richtigen Tastatur sitze, kann ich das mal erläutern, wenn Du willst.

Klar, immer raus mit Deinen Lebenserfahrungen, bist ja hier der erfahrenste Experte auf dem Gebiet der Windows-Server. 
Ich habe mich immer von Windows-Servern entfernt gehalten und lieber Linux benutzt (hauptsächlich aus Preis- und Zeit- Gründen). Linux ist zwar auch nicht immer einfach und man muss viel suchen und lernen aber wenn bei Windows-Netzwerken was klemmt, kommt kann man ohne teuren und erfahrenen MCSE gar nicht weiter. Dazu kommt das Problem, dass man bei Windows viele Dinge einfach nicht ändern kann und sich mit den Einschränkungen abfinden muss.

[Mam]

Klar, immer raus mit Deinen Lebenserfahrungen, bist ja hier der erfahrenste Experte auf dem Gebiet der Windows-Server. 

Lol, wattne Schleimspur legst Du hier hinter Dir ab ? 

Also ok, dann man die lange Version (da mein Lieblingsverein gerade sich nachhaltig und für lange Zeit aus der Champions League verabschiedet und ich mir das Trauerspiel nicht mit ansehen kann):

Also SAMBA hat insgesamt drei Gründe, warum es manche Sachen nicht kann, oder manche Fehler nicht hat:

a) SAMBA wurde von Anfang an auf TCP/IP entwickelt, dadurch musste man sich gar nicht mit dem alten NETBUI Kram rumschlagen, den Microsoft lange Jahre immer so mitgeschleift hat. Deshalb brauchte SAMBA einige Schichten (aka: Timeouts) gar nicht implementieren. Und was nicht da ist, kann nicht haken.

b) SAMBA war anfangs rein re-engineered. Alles, was drin war, war auf Windows Kisten ausgemessen worden und dann umgesetzt. Dabei stimmte natürlich erst einmal einiges nicht, manche Sachen waren falsch verstanden worden. Und viele Sachen waren gar nicht da, da Windows sie nur in bestimmten (seltenen) Kontexten aktiviert. SAMBA war also mehr oder minder "gefrickelt" bzw. "an educated guess". (was trotzdem natürlich ein grossartige Arbeitsleistung war!)

(vor c) muß man noch etwas die weitere Historie wieder ins Gedächtnis rufen, sonst versteht man c nich)

in der folgenden Zeit wurde SAMBA unter den Linux Hackern immer beliebter, es störte niemanden dort, dass viele Sachen (z.B. Verschlüsselung, Passwortspeicher usw.) gar nicht da waren oder nicht funktionierten, denn Otto-normal-Hacker ist eh root und darf grundsätzlich alles.
Irgendwann fing Otto-Normal-Hacker an, aus seinem Lieblings Linux mit entsprechenden Komponenten wie z.B. SAMBA sogenannte "Appliances" zu basteln und an harmlose Anwender zu verkaufen (auch der Hacker muß ja leben).
Dies Treiben nahm reichlich an Fahrt auf und wurde bislang von Microsoft geduldet.

Aber so langsam kamen die Kisten auch in Bereiche vor, die M$ gemeinhin als ihre Kunden bezeichnet und von deren Lizenzeinahmen sie lebt! Da wurd es dann etwas kritischer, denn auf einmal kamen reichlich Supportanfragen bei M$ an, von Kunden, die bei sich in der Firma versuchten, die teuren Windows Server durch billigeres SAMBA zu ersetzen!
Da knirschte es auf einmal an allen Ecken!
Das war zwar (diesmal ausnahmsweise!) nicht die Schuld von M$, aber sie mußten es ausbaden, da ja für den normalen Kunden "der Herr SAMBA" nicht zu greifen ist.
Und natürlich kamen dann auch schnell (vom Linux Lager verbreitet) die entsprechenden Verschwörungstherorien auf, dass M$ bewußt da irgendwas eingebaut hat, um SAMBA auszugrenzen. Klingt plausibel, ist aber Quatsch.

Deshalb passierte dann:

c) M$ setzte sich mit den SAMBA Leuten zusammen, und machte ein Gentleman Agreement: SAMBA bekommt orginal Dokumente, die die Protokolle beschreiben, im Gegenzug müssen sie aber "always one step behind" bleiben.
Ebenso behält M$ bestimmte Erweiterungen unter Verschluß, wobei ich nicht mehr so im Saft stehen und sagen könnte, was aktuell zurückgehalten wird, aber auf jeden Fall erfüllt SAMBA niemals das, was M$ zu einem Zeitpunkt X aufs LAN Kabel bringt.


Inzwischen hat sich der "Markt" ja auch so entwickelt, wie M$ sich das vorgestellt hat. SAMBA ist normalerweise in kleinere Firmen, mit einem einzigen Server, vielleicht sogar inzwischen als Domänencontroller. Für größere Installationen greifen die Leute dann doch lieber zur M$ Schachtel, weil sie eben Sachen wie Remotemangement, Cluster usw. benötigen.

So leben beide nebeneinander her, aber kaum miteinander.
Und deshalb sind sie auch nicht vergleichbar, was beim einen geht, muß beim anderen noch lange nicht funktionieren.

[Cypheros]

Danke für Dein ausführliche Erleuterung.

//***Schleimspur OFF***

Ich sehe MS zwiespältig. Vieles hat MS bei Unix "abgeschaut" und auch recht unfair gespielt in den Jahren von Bill Gates (DR-Dos, Netscape Navigator, Microsoft Kartellverfahren).

Mit Windows Vista haben die Jungs gezeigt, dass ihnen die Kunden scheissegal sind und obwohl Steve Balmer Windows Vista als seinen größten Fehler bezeichnet hat, kam Windows 8, welches genauso am Kunden vorbei entwickelt wurde.

OK, Linux hat auch viel Mist gebaut und ist immer noch nicht attraktiv für dei meisten Anwendungsentwickler, da die Linux-Kunden nicht bereit sind Geld zu bezahlen für brauchbare Anwendungen. Auch der offene Kampf gegen "closed source"-Anwendungen ist kontraproduktiv.

[Mam]

Na ich bin auch kein Fan von den Leuten aus Redmond, allerdings versuche ich immer fair zu bleiben. Wenn sie mal etwas nicht verbockt haben, muss man es auch zugeben.

"Von Unix abgeschaut" ist lustig. Vor allen Dingen, weil es ja eine Zeit gab, in der UNIX (SysV) Microsoft gehörte! (Santa Cruz Operation / SCO).
Sie brauchten also niemanden um Erlaubnis fragen.

Allerdings hat M$ im Laufe der Jahre den TCP Stack nun schon drei (oder gar vier? weis nicht mehr)mal komplett wegeschmissen und neu angefangen. Und natürlich hat man dabei auch in die Referenzimplementation geguckt und sie zur Basis genommen.

Ich konnte mich mit Linux nie wirklich anfreunden, weil es eigentlich kein Linux gibt. Linux ist nur ein Kernel, alles drumrum ist irgendwo "entliehen" und jeder hat da sein eigenes Süppchen gekocht. Da bleib ich lieber bei meinem (Free)BSD, da sind die Verzeichnisse und Dateien immer noch am selben Ort, wie vor 30 Jahren (setzt echt Gehirnmasse frei, man muss nicht nach jedem Update wieder anfangen zu suchen).
Ist allerdings recht langweilig, denn es funktioniert ja einfach so ohne Macken...
(dafür gibts da auch nicht jeden Schnickschnack)

[Cypheros]

Die Linux-Leute sind genauso arrogant wie die Windows-Leute. Hatte mal Problem mit einer integrierten NVidia-Netzwerkkarte, die einfach nicht funktionieren wollte und habe in einigen Foren danach gefragt. Bekam als Anwort, ich solle die Manuals lesen und ggfs den Kernel neu kompilieren. Was soll ein Leihe mit solchen Infos anfangen? Welcher Enduser kompiliert sein OS mal eben schnell neu?
Man wird wie der letzte Depp behandelt...
Drei Wochen später stellte sich heraus, dass durch einen Fehler im Kernel-Sourcecode über 50% aller Netzwerkkarten nicht mehr richtig funktionierten. Danke Linus...