Datenverlust unter Windows 7
Moderator: Moderatoren
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Datenverlust unter Windows 7
So eine Schweinerei ... wie kann M$ nur darauf kommen eine geshared geöffnete Datei auf den Clients zu cachen ....
... sorry, das musste ich mal wieder los werden.
... sorry, das musste ich mal wieder los werden.
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
bitte ganz unten LESEN http://technet.microsoft.com/en-us/libr ... 10%29.aspxHerbert hat geschrieben:"LOCAL_MACHINE\System\CurrentControlSet\Lanmanworkstation\Parameters\DirectoryCacheLifetime"
es heist HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanworkstation\Parameters.
ich habe bislang weitere Kommentare zurück gehalten da ich nicht mit P2P arbeite und ich beim "echten" Server 2008 R2 + "Hotfixe",
bei Domain basierenden User, das Problem nicht habe.
Alaska "meint" zwar das sie ein hätten, aber ich kenne nicht deren Netzwerk Umgebung und "wie" getestet wurde.
um nun P2P überhaupt aufzubauen habe ich 2 "neue" PC frisch mit Win 7 versehen wobei ich als 2nd die 90 Tage Win7 Demo Version benutze.
Die PC waren nicht am Netzwerk oder Router angeschlossen so das Win7 es als "öffentliches" annimmt. mit diese Einstellung habe ich dann auch das Update (52 Fixe) gefahren nachdem ich den Router angeschlossen hatte und das Gateway 192.xxx.xxx.001 eingetragen hatte.
nach den jeweiligen Updates habe ich dann den Router, welche NICHT IP6 fähig ist, entfernt und einen Switch installiert.
Ein PING gelang sofort von beiden PCs, aber man konnte sie noch nicht "sehen".
das liegt nun daran das der Netzwerk Type ja immer noch "öffentlich" ist und da macht die UAC zu.
man muss also den Netzwerktype ändern indem man auf das "nicht identifizierte" Netzwerk clicked (zwischen Computer und Internet) nun sollte man die Freigaben "sehen", die Frage ist nun "was" sehe ich wenn Ihr einen Ordner "Users" seht dann wurde auf dem "Server" eine "HomeGroup" eröffnet.
der Ordner "_e" wurde auf dem "Server" als "Workgroup" angelegt und enthält das Test Verzeichniss
ich habe mich also nur in der grafischen Oberfläche bewegt und auch die "Freigaben", mit der rechten Maustaste, finden im Explorer statt.
bei der Freigabe gibt es im Menu ja 4 Möglichkeiten, wobei bei "niemand" später ein zusätzliches Problem hinzukommt ... (Benutzer/Jeder).
bei "Homegroup" landet man auch in der "Homegroup", aber ich will ja die "Workgroup" also geht das nur über den Benutzer den ich "einladen" (invite) muss.
ich könnte nun, über "verbinden", eine feste Zuordnung einstellen. aber das muss man nicht.
!!! der "Server" MUSS so eingestellt sein das er NICHT in den Energie Sparmodus geht !!!
Nachdem ich nun "so" das Zugriffs Recht auf den Ordner habe fahre ich folgendes Test Programm, aus dem Explorer gestartet.
zu beachten : cHost := "\\A-pc\_e\0"
ändern in euer Verzeichniss
Code: Alles auswählen
#include "Directry.ch"
PROCEDURE Main
LOCAL cHost := "\\A-pc\_e\0"
LOCAL cFile := "TESTOPS.DBF"
LOCAL i
LOCAL nStart
CLS
AEval( Directory(cHost+"\"+"*.NTX"),{ |a| FERASE( cHost+"\"+a[F_NAME] ) } )
IF .NOT. FILE(cHost+"\"+cFile)
C_TESTOPS(cHost+"\"+cFile)
ENDIF
USE (cHost+"\"+cFile) EXCLUSIVE
ZAP
? LASTREC(), RECCOUNT()
WAIT "ready to create Index. press any key ..."
CreateIndex(cHost)
CLOSE DATABASE
nStart := SECONDS()
USE (cHost+"\"+cFile) SHARE
SET INDEX TO (cHost+"\"+"TESTOPS1.NTX"),;
(cHost+"\"+"TESTOPS2.NTX"),;
(cHost+"\"+"TESTOPS3.NTX"),;
(cHost+"\"+"TESTOPS4.NTX"),;
(cHost+"\"+"TESTOPS5.NTX")
? "USE Sec."+TRIM(STR(SECONDS()-nStart))
? ""
? "starte DBF APPEND BLANK, please wait ..."
nStart := SECONDS()
FOR i := 1 TO 20000
APPEND BLANK
REPLACE TESTSTRING WITH Replicate("A",50)
REPLACE TESTNUM WITH RECNO()
REPLACE TESTLOGIC WITH .T.
REPLACE TESTDATE WITH DATE()
REPLACE TESTTIME WITH TIME()
NEXT
? "APPEND BLANK Sec."+TRIM(STR(SECONDS()-nStart))
? LASTREC(), RECCOUNT()
CLOSE DATABASE
WAIT "is it 20000 ? press any key ..."
? "create new Index"
AEval( Directory(cHost+"\"+"*.NTX"),{ |a| FERASE( cHost+"\"+a[F_NAME] ) } )
USE (cHost+"\"+cFile) EXCLUSIVE
CreateIndex(cHost)
? LASTREC(), RECCOUNT()
CLOSE DATABASE
WAIT "still it 20000 ? press any key ..."
USE (cHost+"\"+cFile) SHARE
SET INDEX TO (cHost+"\"+"TESTOPS1.NTX"),;
(cHost+"\"+"TESTOPS2.NTX"),;
(cHost+"\"+"TESTOPS3.NTX"),;
(cHost+"\"+"TESTOPS4.NTX"),;
(cHost+"\"+"TESTOPS5.NTX")
SET ORDER TO 2
SEEK(20000)
IF FOUND()
? "quod erat demonstrandum"
ELSE
? "this is BAD"
ENDIF
? ""
CLOSE DATABASE
WAIT "is FOUND ? press any key ..."
CLS
RETURN
PROCEDURE CreateIndex(cHost)
LOCAL nStart
nStart := SECONDS()
INDEX ON TESTOPS->TESTSTRING TO (cHost+"\"+"TESTOPS1.NTX")
CLOSE INDEX
? "TESTOPS1.NTX Sec."+TRIM(STR(SECONDS()-nStart))
nStart := SECONDS()
INDEX ON TESTOPS->TESTNUM TO (cHost+"\"+"TESTOPS2.NTX")
CLOSE INDEX
? "TESTOPS2.NTX Sec."+TRIM(STR(SECONDS()-nStart))
nStart := SECONDS()
INDEX ON TESTOPS->TESTLOGIC TO (cHost+"\"+"TESTOPS3.NTX")
CLOSE INDEX
? "TESTOPS3.NTX Sec."+TRIM(STR(SECONDS()-nStart))
nStart := SECONDS()
INDEX ON TESTOPS->TESTDATE TO (cHost+"\"+"TESTOPS4.NTX")
CLOSE INDEX
? "TESTOPS4.NTX Sec."+TRIM(STR(SECONDS()-nStart))
nStart := SECONDS()
INDEX ON TESTOPS->TESTTIME TO (cHost+"\"+"TESTOPS5.NTX")
CLOSE INDEX
? "TESTOPS5.NTX Sec."+TRIM(STR(SECONDS()-nStart))
RETURN
function C_TESTOPS(datei,alias,id)
local p,field_list:={}
if valtype(datei)!="C"
datei="TESTOPS.DBF"
endif
if valtype(alias)!="C"
p=at(".",datei)
alias=if(p>0,substr(datei,1,p-1),datei)
endif
if valtype(id)!="N"
id=0
endif
select (id)
if !file(datei)
aadd(field_list,{"TESTSTRING","C",50,0})
aadd(field_list,{"TESTNUM" ,"N",10,0})
aadd(field_list,{"TESTLOGIC" ,"L", 1,0})
aadd(field_list,{"TESTDATE" ,"D", 8,0})
aadd(field_list,{"TESTTIME" ,"C", 8,0})
dbcreate(datei,field_list)
endif
use (datei) alias (alias)
return(.t.)
*
*
*
Anmerkung :
Das Feld "TESTLOGIC" ,"L" habe ich für weitere Betrachtung weg gelassen damit der Source auch mit "anderen" Compiler funktioniert.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
man kann ja leider nur 3 Bilder im Text platzieren ...
also wenn man nun das Testprogramm laufen lässt sollte man den Resource Monitor öffnen. wie ihr unter "Adresse" sehen könnte wird mit einer IP6 "Anfrage" begonnen. Man vergleiche local und remote.
wenn das nun klappt sollte die "Namen-Auflösung" den "Server" anzeigen man achte auf den Datendurchsatz !
was wir nun "wissen" ist das bei SMB2 die MRXSMB2.SYS zuständig ist ... aber welche ? ihr seht die .16xxx sowie die .20xxx Dateien ?
ausser der .7601.16xxx sollten also 4 Varianten vorhanden sein und zumindest eine davon sollte eine .20xxx aufweisen.
p.s. die .7601.16xxx stammt aus dem Service Pack 1 und ist "später" zu betrachten ...
also wenn man nun das Testprogramm laufen lässt sollte man den Resource Monitor öffnen. wie ihr unter "Adresse" sehen könnte wird mit einer IP6 "Anfrage" begonnen. Man vergleiche local und remote.
wenn das nun klappt sollte die "Namen-Auflösung" den "Server" anzeigen man achte auf den Datendurchsatz !
was wir nun "wissen" ist das bei SMB2 die MRXSMB2.SYS zuständig ist ... aber welche ? ihr seht die .16xxx sowie die .20xxx Dateien ?
ausser der .7601.16xxx sollten also 4 Varianten vorhanden sein und zumindest eine davon sollte eine .20xxx aufweisen.
p.s. die .7601.16xxx stammt aus dem Service Pack 1 und ist "später" zu betrachten ...
gruss by OHR
Jimmy
Jimmy
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Re: Datenverlust unter Windows 7
Hallo,
hier nun meine Testergebnisse...
Testumgebung:
Win7-Prof. als Server (64bit)
Win7-Prof als Client (32bit)
Win7-Prof als Client (64bit)
Vista-Prof als Client (32bit)
XP-Client
Ich habe mit dem Beispiel von Chris (veröffentlicht in der Alaska newsgroup) getestet, habe dies aber leicht modifiziert. Im Prinzip macht das Testprogramm nichts anderes, als eine DBF geshared zu öffnen und hängt dann mit append 10.000 Datensätze an. Dieses Testprogramm wird dann parallel auf den Clients gestartet und anschließend wird geprüft, dass die Anzahl der Datensätze in der DBF gleich der Anzahl gestarteter Prozesse * 10000 ist...
Folgende Erkenntnisse über SMB2 und die Probleme und Lösungen konnte ich gewinnen (leider kursieren hier und in anderen Foren einige falsche Wahrheiten):
SMB2 kommt zwischen SMB2-fähigen Betriebssystemen (Vista, Win7, Win2008Server, Win2008R2Server) zum Einsatz, auch wenn Nicht-SMB2-fähige Rechner im gleichen Netzwerk arbeiten und sogar mit dem "Server" verbunden sind (und auch das gleiche Testprogramm läuft). Der Server "spricht" mit einem SMB2-fähigen Client SMB2 und mit einem Nicht-SMB2-fähigen Client eben SMB1.
Ohne den Hotfix von MS, bzw. ohne das manuelle Setzen der 3 Reg-Schalter (FileInfoCacheLifetime=0, FileNotFoundCacheLifetime=0, DirectoryCacheLifetime=0) waren in keinem Falle alle Datensätze in der DBF vorhanden!!! Es haben immer ein paar gefehlt (nie viele). Allerdings konnte ich dieses Problem nur mit der DBFDBE nachvollziehen, nicht mit der FOXDBE. Ganz offensichtlich arbeiten die beiden DBEs in diesem Punkt (append) etwas anders.
Das Problem (zumindest dieses spezielle) lies sich beseitigen
a) durch Installation des Hotfix von MS ODER
b) durch das auf 0 setzen der o. g. Reg-Schalter ODER
c) durch Ausschalten von SMB2 (auf dem "Server")
Das Problem tritt (natürlich) nicht auf, wenn die DBF auf der Freigabe eines Nicht-SMB2-fähigen Betriebssystem liegt, da dann alle Clients mit dem Server über SMB1 kommunizieren.
Weitere Erkenntnisse:
- Unter SMB2 ist OpportunisticLocking immer aktiv (und kann offensichtlich nicht ausgeschaltet werden). Ob das alles gut funktioniert (über diesen speziellen Test hinaus) muss man abwarten...
- Es ist zu empfehlen die beiden Reg-Schalter (FileNotFoundCacheLifetime, DirectoryCacheLifetime) auf jeden Fall auf 0 zu setzen. Die funktionieren wirklich (mit und ohne Hotfix). Es dauert sonst in der Tat einige Sekunden, bis ein file() oder ein fexists() eine Datei "sieht", die von einem anderen Client erzeugt wurde.
- Die Hotfixe (verschiedene für Vista/2008 und Win7/2008R2, jeweils in der 32 und 64bit-Variante) müssen bei MS angefordert werden und sind mit einem Passwort versehen, welches nur 8 Tage funktioniert. Ohne Worte!!!
- Der Hotfix wird Bestandteil von SP1 für Win7/2008R2, bzw. SP3 für Vista/2008 sein (lt. Hotfix-Seite von MS)
- Bei dem Testprogramm kommt es bei der FOXDBE immer wieder zu Xbase-Runtime-Fehlern (IDSC oder 8999er) wenn SMB2 aktiv ist, auch mit Hotfix und mit den gesetzten Reg-Schaltern!!! Das passiert zwar nicht in jedem Testlauf, aber immer mal wieder.
GANZ WICHTIG:
Die Reg-Schalter FileInfoCacheLifetime=0, FileNotFoundCacheLifetime=0, DirectoryCacheLifetime=0 gehören in den Zweig HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters. Leider wurde das von Alaska falsch kommuniziert (und ist auch in deren Tool falsch). Sogar in der MSDN ist das teilweise falsch beschrieben (da hat Alaska das wohl herkopiert).
Mein Fazit:
Ich werde bei meinen Anwendern weiterhin (wie seit Vista) SMB2 am Server ausschalten. Zumindest bis die ServicePacks draussen sind. Die anzufordernden-ablauf-passwort-gesicherten Hotfixe zu installieren ist eine Zumutung. Allerdings kommt es wie oben geschrieben ja unter FOXDBE zumindest bei der dbappend()-Orgie dieses Testprogrammes immer wieder mal zu Runtime-Errors. Das muss ich also im Auge behalten...
hier nun meine Testergebnisse...
Testumgebung:
Win7-Prof. als Server (64bit)
Win7-Prof als Client (32bit)
Win7-Prof als Client (64bit)
Vista-Prof als Client (32bit)
XP-Client
Ich habe mit dem Beispiel von Chris (veröffentlicht in der Alaska newsgroup) getestet, habe dies aber leicht modifiziert. Im Prinzip macht das Testprogramm nichts anderes, als eine DBF geshared zu öffnen und hängt dann mit append 10.000 Datensätze an. Dieses Testprogramm wird dann parallel auf den Clients gestartet und anschließend wird geprüft, dass die Anzahl der Datensätze in der DBF gleich der Anzahl gestarteter Prozesse * 10000 ist...
Folgende Erkenntnisse über SMB2 und die Probleme und Lösungen konnte ich gewinnen (leider kursieren hier und in anderen Foren einige falsche Wahrheiten):
SMB2 kommt zwischen SMB2-fähigen Betriebssystemen (Vista, Win7, Win2008Server, Win2008R2Server) zum Einsatz, auch wenn Nicht-SMB2-fähige Rechner im gleichen Netzwerk arbeiten und sogar mit dem "Server" verbunden sind (und auch das gleiche Testprogramm läuft). Der Server "spricht" mit einem SMB2-fähigen Client SMB2 und mit einem Nicht-SMB2-fähigen Client eben SMB1.
Ohne den Hotfix von MS, bzw. ohne das manuelle Setzen der 3 Reg-Schalter (FileInfoCacheLifetime=0, FileNotFoundCacheLifetime=0, DirectoryCacheLifetime=0) waren in keinem Falle alle Datensätze in der DBF vorhanden!!! Es haben immer ein paar gefehlt (nie viele). Allerdings konnte ich dieses Problem nur mit der DBFDBE nachvollziehen, nicht mit der FOXDBE. Ganz offensichtlich arbeiten die beiden DBEs in diesem Punkt (append) etwas anders.
Das Problem (zumindest dieses spezielle) lies sich beseitigen
a) durch Installation des Hotfix von MS ODER
b) durch das auf 0 setzen der o. g. Reg-Schalter ODER
c) durch Ausschalten von SMB2 (auf dem "Server")
Das Problem tritt (natürlich) nicht auf, wenn die DBF auf der Freigabe eines Nicht-SMB2-fähigen Betriebssystem liegt, da dann alle Clients mit dem Server über SMB1 kommunizieren.
Weitere Erkenntnisse:
- Unter SMB2 ist OpportunisticLocking immer aktiv (und kann offensichtlich nicht ausgeschaltet werden). Ob das alles gut funktioniert (über diesen speziellen Test hinaus) muss man abwarten...
- Es ist zu empfehlen die beiden Reg-Schalter (FileNotFoundCacheLifetime, DirectoryCacheLifetime) auf jeden Fall auf 0 zu setzen. Die funktionieren wirklich (mit und ohne Hotfix). Es dauert sonst in der Tat einige Sekunden, bis ein file() oder ein fexists() eine Datei "sieht", die von einem anderen Client erzeugt wurde.
- Die Hotfixe (verschiedene für Vista/2008 und Win7/2008R2, jeweils in der 32 und 64bit-Variante) müssen bei MS angefordert werden und sind mit einem Passwort versehen, welches nur 8 Tage funktioniert. Ohne Worte!!!
- Der Hotfix wird Bestandteil von SP1 für Win7/2008R2, bzw. SP3 für Vista/2008 sein (lt. Hotfix-Seite von MS)
- Bei dem Testprogramm kommt es bei der FOXDBE immer wieder zu Xbase-Runtime-Fehlern (IDSC oder 8999er) wenn SMB2 aktiv ist, auch mit Hotfix und mit den gesetzten Reg-Schaltern!!! Das passiert zwar nicht in jedem Testlauf, aber immer mal wieder.
GANZ WICHTIG:
Die Reg-Schalter FileInfoCacheLifetime=0, FileNotFoundCacheLifetime=0, DirectoryCacheLifetime=0 gehören in den Zweig HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters. Leider wurde das von Alaska falsch kommuniziert (und ist auch in deren Tool falsch). Sogar in der MSDN ist das teilweise falsch beschrieben (da hat Alaska das wohl herkopiert).
Mein Fazit:
Ich werde bei meinen Anwendern weiterhin (wie seit Vista) SMB2 am Server ausschalten. Zumindest bis die ServicePacks draussen sind. Die anzufordernden-ablauf-passwort-gesicherten Hotfixe zu installieren ist eine Zumutung. Allerdings kommt es wie oben geschrieben ja unter FOXDBE zumindest bei der dbappend()-Orgie dieses Testprogrammes immer wieder mal zu Runtime-Errors. Das muss ich also im Auge behalten...
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Datenverlust unter Windows 7
Dank dir Markus, Superseriös und begreiflich und professionell!
Das Passwort läuft nur im gedownloadeten, Patch ab, den du in selbstextrahierender, gezippten Form vor dir hast. Du kannst diesen sofort extrahieren und kriegst so das "ewig" lebende Installationsfile mit der Endung ".msu". Also halb so wild.
Das Passwort läuft nur im gedownloadeten, Patch ab, den du in selbstextrahierender, gezippten Form vor dir hast. Du kannst diesen sofort extrahieren und kriegst so das "ewig" lebende Installationsfile mit der Endung ".msu". Also halb so wild.
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
FALSCH !!!Markus Walter hat geschrieben:Mein Fazit:
Ich werde bei meinen Anwendern weiterhin (wie seit Vista) SMB2 am Server ausschalten.
Warum meinst du wohl das ich so ausführlich mit Bildern die Test Umgebung beschreibe ?!
wenn man SMB2 verwenden will muss man dafür sorgen das keine SMB1 Geräte im Netzwerk sind.
Deshalb habe ich auch geschrieben das ich den NICHT IP6 fähigen Router gegen eine Switch getauscht habe.
Von den "billigen" Routern ist nur die Fritzbox, wo es seit 2 Wochen ein Update gibt, IP6 fähig
ansonsten findet man bei den "professionellen" Router welche ab 1000 Euro,-
Das SMB2 IP6 benutzt habe ich auch in den Bildern gezeigt, vergleiche local/remote Port.
Da SMB2 Daten auch komprimiert sind deutlich höhere Datenraten möglich, über 80 MBit in einem 100Mbit Netzwerk.
Das man eine XP Station, ohne KB922120, nicht in der Win 7 Netzwerk Übersicht auftaucht wisst ihr ja auch,
aber wie man es auf eine XP SP3 Station "installiert" weiss wohl keiner von euch, oder ?
wenn ihr also dann mit "Trick" und "einfacher Freigabe" die XP Stationen "scheinbar" zu arbeiten gebracht habt
so habt ihr in Wirklichkeit schon das Chaos angerichtet.
Windows "merkt" sich die Einstellungen auch wenn die nicht mehr im Netzwerk sind und sucht ... und sucht ...
in solche Fällen hilft es nur noch bei jeder Workstation ein IPCONFIG /flushdns um den DNS Cache zu leeren.
Das Problem von Chris und Co. liegt an euer Test Umgebung, "so" kann das nicht funktionieren.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
hi,
bei Windows 7 haben wir 4 Netzwerk Typen :
Öffentliches-
Domänen-
Arbeitsplatz-
Heim-Netzwerk
Wenn man nun 2x Win7 PCs "nur" per Switch verbindet bekommt man die Meldung "nicht identifizierbares Netzwerk"
obwohl sie beide im selben Netzwerk Segment hängen. (192.xxx.xxx.xxx)
Auch kann man in so einem Fall weder auf Arbeitsplatz- noch Heim-Netzwerk wechseln.
unter XP wird, per LLTD, "nur" festgestellt ob ein Netzwerk aktive ist ... also ob das Kabel angeschlossen ist.
ab Vista / Win 7 erkennt NLA die verschiedenen Netzwerk Typen sodass das OS() erkennt welche Einstellungen es, z.b. für den Firewall, wählen soll.
Gehört der PC nun zu einer Domäne, werden die Einstellungen vom Domänen Controller, also dem Server, "eingestellt".
kann Win7 ein Netzwerk nicht identifizieren dann "sollte" ein Popup erscheinen, ansonsten wird es als "öffentliches-" Netzwerk eingestuft.
Vista / Win 7 nutzen zwar beide das private Firewall Profile für beide, Heim- und Arbeitsplatz- Netzwerk, aber Win7 unterscheidet die beiden Netzwerk Typen !
bei der Freigabe, rechte Maustaste, sind im Menue 4 Auswahl Möglichkeiten.
die schnell Freigabe (einfache Freigabe) funktioniert nur im Heim- Netzwerk ( HomeGroup )
während die Benutzer definierte Version einen User und Passwort verlangt ( WorkGroup )
PCs an einen Domänen angeschlossen ( WorkGroup ) übernehmen ja deren Profil die auch weniger Regeln enthält als alle anderen Netzwerk Typen.
PCs ohne Domänen (unmanaged) werden vom Netzwerk Type an der Gateway Adresse "erkannt" was meistens dann der Router wäre
( wenn es nicht noch andere DHCP Host gibt )
Wenn man also 2x Win 7 PCs und einem Switch verbindet benötigen die PCs einen Gateway Eintrag !
Dies könnte, ausser dem Server, z.b der Router oder Netzwerk Drucker sein.
was aber nun mit dem nicht IP6 fähigem Router ?
Der Trick heisst 2nd Netzwerkkarte im "Server" (dual-homed)
bislang habe ich ja nur Win 7 betrachtet, Vista SP2 eingeschlossen, aber was ist mit XP ?
unter http://www.microsoft.com/downloads/deta ... f485fa34ea
findet man zwar einen "Hotfix", aber der lässt sich nicht unter XP SP3 installieren der der ist für "Windows XP Service Pack 2"
unter http://support.microsoft.com/kb/922120 ist nun die KB922120 Erklärung und gleich ganz oben ist ein Link zum "anfordern".
http://support.microsoft.com/hotfix/KBH ... 20&kbln=de
dort bekommt man dann das angeboten was man da bekommt ist nun die V6 (WindowsXP-KB922120-v6-x86-DEU.exe) für XP SP3 und dann hat man 2 neue Dateien auf dem PC :
Rspndr.exe und Rspndr.sys.
diese beiden Dateien sorgen erst dafür das sich XP "richtig" mit Win 7 "unterhalten" KANN !!!
ohne den neuen "Network Topology Responder Protocol Driver for NDIS 6" bekommt man eine XP Workstation
nicht in ein Arbeitsplatz- (WorkGroup) sondern nur in ein Heim-Netzwerk (HomeGroup).
Wer nun ein Heim-Netzwerk (HomeGroup), wo ja alle User etliche Rechte haben, arbeiten will
sollte sich zumindest den "alten" WHS ( Windows-Home-Server ) ansehen.
So was gibt es schon "fertig", meistens auf Basis der Atom CPUs, welcher bis 10 User Lizenzen ausgelegt ist.
Der WHS v1.x basiert auf dem W2K3 Server und bietet für ein Heim-Netzwerk ( HomeGroup ) erst eine vernünftige Rechte Verwaltung
insbesondere bei gemeinsamen Internet Zugriff.
!!! Warnung : das Upgrade auf WHS v2.x ("Vail") ist nicht WHS v1.x kompatible !!!
Wer nun versucht einen XP als "Server" für Win 7 Stationen laufen zu lassen oder SMB2 "ab-zu-schalten",
dem kann ich auch nicht helfen...
... man kann ja auch gleich beim Netzwerk Protokoll das IP6 Protokoll raus nehmen und nur noch IP4 fahren ... wenn man will ...
sorry Jungs, eure Heim-Netzwerke ( HomeGroup ) mögen vielleicht eurem Standard genügen, aber ich fahre ungern mit "angezogener Handbremse" über eine "Buckel-Piste" ( Netzwerk Protokolle ) und "öffentlichen Freigaben" in einem Firmen Arbeitsplatz-Netzwerk ( WorkGroup )
zum Thema LLTD http://technet.microsoft.com/de-de/libr ... S.10).aspx
was nun "Opportunistic locking" angeht kann ich nur auf http://www.xbaseforum.de/viewtopic.php?f=21&t=1567 verweisen,
die "Einträge" sind allerdings nur bis XP ausgelegt (keine OS() Version abfrage etc )
eine "SMB2" Version ist in Arbeit ...
bei Windows 7 haben wir 4 Netzwerk Typen :
Öffentliches-
Domänen-
Arbeitsplatz-
Heim-Netzwerk
Wenn man nun 2x Win7 PCs "nur" per Switch verbindet bekommt man die Meldung "nicht identifizierbares Netzwerk"
obwohl sie beide im selben Netzwerk Segment hängen. (192.xxx.xxx.xxx)
Auch kann man in so einem Fall weder auf Arbeitsplatz- noch Heim-Netzwerk wechseln.
unter XP wird, per LLTD, "nur" festgestellt ob ein Netzwerk aktive ist ... also ob das Kabel angeschlossen ist.
ab Vista / Win 7 erkennt NLA die verschiedenen Netzwerk Typen sodass das OS() erkennt welche Einstellungen es, z.b. für den Firewall, wählen soll.
Gehört der PC nun zu einer Domäne, werden die Einstellungen vom Domänen Controller, also dem Server, "eingestellt".
kann Win7 ein Netzwerk nicht identifizieren dann "sollte" ein Popup erscheinen, ansonsten wird es als "öffentliches-" Netzwerk eingestuft.
Vista / Win 7 nutzen zwar beide das private Firewall Profile für beide, Heim- und Arbeitsplatz- Netzwerk, aber Win7 unterscheidet die beiden Netzwerk Typen !
bei der Freigabe, rechte Maustaste, sind im Menue 4 Auswahl Möglichkeiten.
die schnell Freigabe (einfache Freigabe) funktioniert nur im Heim- Netzwerk ( HomeGroup )
während die Benutzer definierte Version einen User und Passwort verlangt ( WorkGroup )
PCs an einen Domänen angeschlossen ( WorkGroup ) übernehmen ja deren Profil die auch weniger Regeln enthält als alle anderen Netzwerk Typen.
PCs ohne Domänen (unmanaged) werden vom Netzwerk Type an der Gateway Adresse "erkannt" was meistens dann der Router wäre
( wenn es nicht noch andere DHCP Host gibt )
Wenn man also 2x Win 7 PCs und einem Switch verbindet benötigen die PCs einen Gateway Eintrag !
Dies könnte, ausser dem Server, z.b der Router oder Netzwerk Drucker sein.
was aber nun mit dem nicht IP6 fähigem Router ?
Der Trick heisst 2nd Netzwerkkarte im "Server" (dual-homed)
bislang habe ich ja nur Win 7 betrachtet, Vista SP2 eingeschlossen, aber was ist mit XP ?
unter http://www.microsoft.com/downloads/deta ... f485fa34ea
findet man zwar einen "Hotfix", aber der lässt sich nicht unter XP SP3 installieren der der ist für "Windows XP Service Pack 2"
unter http://support.microsoft.com/kb/922120 ist nun die KB922120 Erklärung und gleich ganz oben ist ein Link zum "anfordern".
http://support.microsoft.com/hotfix/KBH ... 20&kbln=de
dort bekommt man dann das angeboten was man da bekommt ist nun die V6 (WindowsXP-KB922120-v6-x86-DEU.exe) für XP SP3 und dann hat man 2 neue Dateien auf dem PC :
Rspndr.exe und Rspndr.sys.
diese beiden Dateien sorgen erst dafür das sich XP "richtig" mit Win 7 "unterhalten" KANN !!!
ohne den neuen "Network Topology Responder Protocol Driver for NDIS 6" bekommt man eine XP Workstation
nicht in ein Arbeitsplatz- (WorkGroup) sondern nur in ein Heim-Netzwerk (HomeGroup).
Wer nun ein Heim-Netzwerk (HomeGroup), wo ja alle User etliche Rechte haben, arbeiten will
sollte sich zumindest den "alten" WHS ( Windows-Home-Server ) ansehen.
So was gibt es schon "fertig", meistens auf Basis der Atom CPUs, welcher bis 10 User Lizenzen ausgelegt ist.
Der WHS v1.x basiert auf dem W2K3 Server und bietet für ein Heim-Netzwerk ( HomeGroup ) erst eine vernünftige Rechte Verwaltung
insbesondere bei gemeinsamen Internet Zugriff.
!!! Warnung : das Upgrade auf WHS v2.x ("Vail") ist nicht WHS v1.x kompatible !!!
Wer nun versucht einen XP als "Server" für Win 7 Stationen laufen zu lassen oder SMB2 "ab-zu-schalten",
dem kann ich auch nicht helfen...
... man kann ja auch gleich beim Netzwerk Protokoll das IP6 Protokoll raus nehmen und nur noch IP4 fahren ... wenn man will ...
sorry Jungs, eure Heim-Netzwerke ( HomeGroup ) mögen vielleicht eurem Standard genügen, aber ich fahre ungern mit "angezogener Handbremse" über eine "Buckel-Piste" ( Netzwerk Protokolle ) und "öffentlichen Freigaben" in einem Firmen Arbeitsplatz-Netzwerk ( WorkGroup )
zum Thema LLTD http://technet.microsoft.com/de-de/libr ... S.10).aspx
was nun "Opportunistic locking" angeht kann ich nur auf http://www.xbaseforum.de/viewtopic.php?f=21&t=1567 verweisen,
die "Einträge" sind allerdings nur bis XP ausgelegt (keine OS() Version abfrage etc )
eine "SMB2" Version ist in Arbeit ...
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
aber "interessant" ist das mit dem "ablaufenden" Passwort schon ... "wie" macht man das ?Herbert hat geschrieben:Das Passwort läuft nur im gedownloadeten, Patch ab, den du in selbstextrahierender, gezippten Form vor dir hast. Du kannst diesen sofort extrahieren und kriegst so das "ewig" lebende Installationsfile mit der Endung ".msu". Also halb so wild.
gruss by OHR
Jimmy
Jimmy
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Re: Datenverlust unter Windows 7
Hallo,
also Jimmy, ganz im Ernst:
Meine Testergebnisse waren eindeutig. Und ich habe bei über 750 Kunden keinen Einfluss wie die Netze vor Ort aussehen (vor allem, da Du teilweise abstruse Theorien aufstellst, die kein Mensch testen/nachvollziehen kann).
Dazu kommt, dass ich schon vor diesem Testszenario bei 2 Anwendern, bei denen SMB2 eben nicht ausgeschaltet war, massive Probleme hatten, die sofort weg waren, als SMB2 ausgeschaltet wurde (sonst wurde NIX gemacht).
Du kannst ja machen was Du willst. Ich werde es anders machen. Das Du aber eindeutige Testergebnisse, die in 3-Mann-Tagen Test ermittelt wurden, plus zusätzliche Erfahrungen aus mehreren hundert installierten Mehrplatzanlagen mit einem fettgedruckten "FALSCH!!!" quittierst, halte ich nicht für die feine englische Art. Zumal Du in Deinen Postings zu dem Thema definitiv falsche Aussagen gemacht hast.
also Jimmy, ganz im Ernst:
Meine Testergebnisse waren eindeutig. Und ich habe bei über 750 Kunden keinen Einfluss wie die Netze vor Ort aussehen (vor allem, da Du teilweise abstruse Theorien aufstellst, die kein Mensch testen/nachvollziehen kann).
Dazu kommt, dass ich schon vor diesem Testszenario bei 2 Anwendern, bei denen SMB2 eben nicht ausgeschaltet war, massive Probleme hatten, die sofort weg waren, als SMB2 ausgeschaltet wurde (sonst wurde NIX gemacht).
Du kannst ja machen was Du willst. Ich werde es anders machen. Das Du aber eindeutige Testergebnisse, die in 3-Mann-Tagen Test ermittelt wurden, plus zusätzliche Erfahrungen aus mehreren hundert installierten Mehrplatzanlagen mit einem fettgedruckten "FALSCH!!!" quittierst, halte ich nicht für die feine englische Art. Zumal Du in Deinen Postings zu dem Thema definitiv falsche Aussagen gemacht hast.
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Re: Datenverlust unter Windows 7
Hallo Herbert,Herbert hat geschrieben:Dank dir Markus, Superseriös und begreiflich und professionell!
Das Passwort läuft nur im gedownloadeten, Patch ab, den du in selbstextrahierender, gezippten Form vor dir hast. Du kannst diesen sofort extrahieren und kriegst so das "ewig" lebende Installationsfile mit der Endung ".msu". Also halb so wild.
okay, das würde die Sache vereinfachen.
Trotzdem solltest Du die 3 Reg-Schalter auf 0 setzen und nicht nur den Hotfix einspielen. Auch der Hotfix ändert nichts an der Tatsache, dass der Client die Datei- und Verzeichnis-Metainformationen cached und es mehrere Sekunden dauern kann, bis z. B. ein Client eine neue Datei "sieht", die von einem anderen Client erzeugt wurde. It's not a bug, it's a feature.
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Datenverlust unter Windows 7
Klar, das mach ich so.Markus Walter hat geschrieben: Trotzdem solltest Du die 3 Reg-Schalter auf 0 setzen und nicht nur den Hotfix einspielen. Auch der Hotfix ändert nichts an der Tatsache, dass der Client die Datei- und Verzeichnis-Metainformationen cached und es mehrere Sekunden dauern kann, bis z. B. ein Client eine neue Datei "sieht", die von einem anderen Client erzeugt wurde. It's not a bug, it's a feature.
Für mich ist einzig unklar, warum Thomas nur mit dem einen Registry-Eintrag Erfolg hat (DirectoryCacheLifetime) und sobald er die andern 2 einspielt, weider Schwierigkeiten hat...
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Datenverlust unter Windows 7
Hi,AUGE_OHR hat geschrieben:aber "interessant" ist das mit dem "ablaufenden" Passwort schon ... "wie" macht man das ?Herbert hat geschrieben:Das Passwort läuft nur im gedownloadeten, Patch ab, den du in selbstextrahierender, gezippten Form vor dir hast. Du kannst diesen sofort extrahieren und kriegst so das "ewig" lebende Installationsfile mit der Endung ".msu". Also halb so wild.
das Passwort läuft nicht ab und man braucht das auch nicht zum DownLoad.
Wenn man aber den Fixpack einspielen will, dann muss man das Passwort eingeben.
Ob die Ausführung auch - wie der LINK - zeitlich begrenzt ist weiß ich nicht, aber ...
sobald der ServicePack raus ist, macht es ja keinen Sinn mehr und
M$ muss seine downloadserver auch mal wieder reinigen (wenn weltweit jeder 100. das anfordert ...)
Gruß
Hubert
Hubert
- Markus Walter
- Programmier-Gott
- Beiträge: 1018
- Registriert: Di, 24. Jan 2006 10:22
- Wohnort: Saarland
Re: Datenverlust unter Windows 7
Hallo Herbert,Herbert hat geschrieben:Klar, das mach ich so.Markus Walter hat geschrieben: Trotzdem solltest Du die 3 Reg-Schalter auf 0 setzen und nicht nur den Hotfix einspielen. Auch der Hotfix ändert nichts an der Tatsache, dass der Client die Datei- und Verzeichnis-Metainformationen cached und es mehrere Sekunden dauern kann, bis z. B. ein Client eine neue Datei "sieht", die von einem anderen Client erzeugt wurde. It's not a bug, it's a feature.
Für mich ist einzig unklar, warum Thomas nur mit dem einen Registry-Eintrag Erfolg hat (DirectoryCacheLifetime) und sobald er die andern 2 einspielt, weider Schwierigkeiten hat...
ich habe mir nicht die Mühe gemacht, die ganzen Testläufe auch mit einzel gesetzten Schaltern (und den 2er Kombinationen) zu machen. Ich setze alle und damit ging es. Ich habe nur ganz am Anfang mal nur einen gesetzt und zwar den FileInfoCacheLifetime. Weil ich den als verantwortlich für das dbappend-Problem gesehen habe. Allerdings war in der Kombination (also FileInfoCacheLifetime=0 und die beiden anderen nicht gesetzt, dadurch Standardwerte) ein einfaches dbzap() nicht mehr möglich (es erfolgte immer ein Absturz und die dbname.$$$-Datei war noch da - also ging irgendwie die letzte Umbenennung nicht).
Faktum für mich war, dass meine Tests erfolgreich waren, wenn alle drei Schalter auf 0 gesetzt waren und sich dann das Ganze auch so verhält, wie man es erwartet, nämlich das neue Dateien, die von einem anderen Client erzeugt werden, auch sofort sichtbar sind.
Ich habe übrigens auch mit Steffen gemailt, die sind auch noch am Testen...
Gruß
Markus
Mitglied der XUG Saarland-Pfalz
Markus
Mitglied der XUG Saarland-Pfalz
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
eindeutig FALSCH getestetMarkus Walter hat geschrieben:Meine Testergebnisse waren eindeutig.
die sollen sich einen CNA holenMarkus Walter hat geschrieben:Und ich habe bei über 750 Kunden keinen Einfluss wie die Netze vor Ort aussehen
Das ist keine Theorie sondern das was in meine Unterlagen steht.Markus Walter hat geschrieben:(vor allem, da Du teilweise abstruse Theorien aufstellst, die kein Mensch testen/nachvollziehen kann).
Ich habe auch überall einen Hinweis oder Link aufgeführt. wo sind deine "Beweise" ?
wie ich sagte : GANZ GROSSER MIST !!!Markus Walter hat geschrieben:Dazu kommt, dass ich schon vor diesem Testszenario bei 2 Anwendern, bei denen SMB2 eben nicht ausgeschaltet war, massive Probleme hatten, die sofort weg waren, als SMB2 ausgeschaltet wurde (sonst wurde NIX gemacht).
Ich habe schon vor 2 Jahren, als der "beta" Test los ging mich mich dem Thema beschäftigt. Dies kannst du im Forum nachlesen.Markus Walter hat geschrieben:Du kannst ja machen was Du willst. Ich werde es anders machen. Das Du aber eindeutige Testergebnisse, die in 3-Mann-Tagen Test ermittelt wurden, plus zusätzliche Erfahrungen aus mehreren hundert installierten Mehrplatzanlagen mit einem fettgedruckten "FALSCH!!!" quittierst, halte ich nicht für die feine englische Art.
Letztes Jahr als Win 7 "offiziell" released wurde habe ich mein erstes Win 7 Netzwerk installiert wobei mir die ersten Probleme aufgefallen sind.
Ich habe dann, auf Empfehlung eines Bekannten, eine CNA Kurs besucht wo man uns die Feinheiten erklärte.
welche Aussage soll falsch sein ?Markus Walter hat geschrieben:Zumal Du in Deinen Postings zu dem Thema definitiv falsche Aussagen gemacht hast.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
VORSICHT !!!brandelh hat geschrieben:sobald der ServicePack raus ist, macht es ja keinen Sinn mehr
Richtig ist das im Service Pack 1 eine MRXSMB20.SYS vorhanden ist, aber welche Version ?
die "beta" hat ja die 7601.16562 also eine v16xxx, aber wir sprechen von der .v20xxx
die "Release Candidate" wurde jetzt ja freigegeben, mal sehen welche Version dort enthalten ist.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
was mich interessieren würde :
a.) was für einen Datendurchsatz hab ihr in euren Win 7 Netzwerken ?
b.) benutzt jemand "search Index" unter Win 7 und welche iFilter habt ihr eingebunden ?
a.) was für einen Datendurchsatz hab ihr in euren Win 7 Netzwerken ?
b.) benutzt jemand "search Index" unter Win 7 und welche iFilter habt ihr eingebunden ?
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
hi,
Ich hoffe das meine Ausführungen bislang klar sind und euch eine Idee davon gibt was Win 7 im Netzwerk macht.
sollte etwas nicht klar sein bitte ich um Nachfrage, ich versuche es dann anders zu erklären.
Ich hatte ja gesagt, wie man es auch auf den Bildern erkennen kann, das Win 7 zuerst eine IP6 "Anfrage" versucht, was man auch "Handshake" nennen könnte.
wenn Win 7 nun die IP6 Adresse "auflösen" kann treten einige "interne" SMB2 spezifische Aktionen in Gang.
Als Beispiel will ich hier den Remote Desktop nehmen. Umgebung wie vorher 2x Win 7 und Switch.
Ich "sehe" sie in der Netzwerk Umgebung und habe "Zugriff" bin aber noch nicht bei "Server" angemeldet und habe noch kein Laufwerk gemapped.
wenn ich nun den Remote Desktop starte kommt das Login mit User und Passwort, dann dauert es ...
nach einiger Zeit kommt ein Pop-up und es wird ein "Zertifikat" angezeigt. Dieses sollte man sich genauer ansehen !
es wird einem auffallen das es "zeitlich" begrenzt ist und mit jeder Sitzung erneuert wird.
warum ich das nun erzähle ? nun bei SMB2 erfolgt dieses Schema bei "jeder" Übertragung !
bei jeder Connection die ich über die WorkGroup herstelle wird eine Authentifizierung "erwartet" und dafür gibt es die "zeitlich" begrenzten "Zertifikate".
Die Geschwindigkeit in einem "richtig" konfigurierten SMB2 Netzwerk ist deutlich höher als bei SMB1 (siehe Bilder als BEWEIS)
Bei den Arbeitsplatz- PCs (WorkGroup), welche an die Domänen angeschlossen sind, läuft bis zu 4 Stationen bei gleichzeitigen Zugriff
auf den "echten" Server und den "anderen" Servern alles auf "volle Kraft".
Danach bricht die P2P auf 30-40Mbit, also "normal", zusammen während die "echte" Server Verbindung immer noch 70-80Mbit "bringt".
Der Unterschied zwischen einem "echten" Server 2008 und einem WorkGroup P2P Server wird also erst unter Last bemerkbar ,
wenn die Prioritäten eingreifen bevor das Netzwerk "zu-gemüllt" wird.
***
ein Grund warum WHS v2.x ("Vail") auf der Srv2009 ("Aurora") aufbaut ist der Wunsch mehrere "Media Streams" gleichzeitig zu übertragen.
z.Z. können alle Home-Clients ( HomeGroup ) zwar per UPNP sich an den Media Server ankoppeln, aber alle "sehen" das "selbe" bei Video.
Bei Audio kann sich jeder Home-Client, über freigegebene Media "Bibliotheken", sein "eigenes" Programm zusammenstellen.
***
wenn nun XP ins Spiel kommt funktioniert das nicht mehr weil XP kein SMB2 kennt, also wird "runter-geschaltet".
btw. mit dem KB922120 v6.x ( WindowsXP-KB922120-v6-x86-DEU.exe ) kann man zwar XP in einem SMB2 Netzwerk fahren, aber nur als Workstation.
überhaupt ist es "bekannt" das man niemals eine "niedrige" Version als "Server" benutzen sollte
Ich hoffe das meine Ausführungen bislang klar sind und euch eine Idee davon gibt was Win 7 im Netzwerk macht.
sollte etwas nicht klar sein bitte ich um Nachfrage, ich versuche es dann anders zu erklären.
Ich hatte ja gesagt, wie man es auch auf den Bildern erkennen kann, das Win 7 zuerst eine IP6 "Anfrage" versucht, was man auch "Handshake" nennen könnte.
wenn Win 7 nun die IP6 Adresse "auflösen" kann treten einige "interne" SMB2 spezifische Aktionen in Gang.
Als Beispiel will ich hier den Remote Desktop nehmen. Umgebung wie vorher 2x Win 7 und Switch.
Ich "sehe" sie in der Netzwerk Umgebung und habe "Zugriff" bin aber noch nicht bei "Server" angemeldet und habe noch kein Laufwerk gemapped.
wenn ich nun den Remote Desktop starte kommt das Login mit User und Passwort, dann dauert es ...
nach einiger Zeit kommt ein Pop-up und es wird ein "Zertifikat" angezeigt. Dieses sollte man sich genauer ansehen !
es wird einem auffallen das es "zeitlich" begrenzt ist und mit jeder Sitzung erneuert wird.
warum ich das nun erzähle ? nun bei SMB2 erfolgt dieses Schema bei "jeder" Übertragung !
bei jeder Connection die ich über die WorkGroup herstelle wird eine Authentifizierung "erwartet" und dafür gibt es die "zeitlich" begrenzten "Zertifikate".
Die Geschwindigkeit in einem "richtig" konfigurierten SMB2 Netzwerk ist deutlich höher als bei SMB1 (siehe Bilder als BEWEIS)
Bei den Arbeitsplatz- PCs (WorkGroup), welche an die Domänen angeschlossen sind, läuft bis zu 4 Stationen bei gleichzeitigen Zugriff
auf den "echten" Server und den "anderen" Servern alles auf "volle Kraft".
Danach bricht die P2P auf 30-40Mbit, also "normal", zusammen während die "echte" Server Verbindung immer noch 70-80Mbit "bringt".
Der Unterschied zwischen einem "echten" Server 2008 und einem WorkGroup P2P Server wird also erst unter Last bemerkbar ,
wenn die Prioritäten eingreifen bevor das Netzwerk "zu-gemüllt" wird.
***
ein Grund warum WHS v2.x ("Vail") auf der Srv2009 ("Aurora") aufbaut ist der Wunsch mehrere "Media Streams" gleichzeitig zu übertragen.
z.Z. können alle Home-Clients ( HomeGroup ) zwar per UPNP sich an den Media Server ankoppeln, aber alle "sehen" das "selbe" bei Video.
Bei Audio kann sich jeder Home-Client, über freigegebene Media "Bibliotheken", sein "eigenes" Programm zusammenstellen.
***
wenn nun XP ins Spiel kommt funktioniert das nicht mehr weil XP kein SMB2 kennt, also wird "runter-geschaltet".
btw. mit dem KB922120 v6.x ( WindowsXP-KB922120-v6-x86-DEU.exe ) kann man zwar XP in einem SMB2 Netzwerk fahren, aber nur als Workstation.
überhaupt ist es "bekannt" das man niemals eine "niedrige" Version als "Server" benutzen sollte
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
hi,
nachdem das XP "Network Topology Responder Protocol Driver for NDIS 6" Problem schon vorgezogen wurde
möchte ich wieder zum Redirector MRXSMB20.SYS kommen.
bei eine "frischen" Win7 Demo Installation und den Updates (51 Hotfix +1 Netzwerkkarte)
hat man 4x MRXSMB20.SYS auf dem PC.
sehen wir und die doch mal "genauer" an, erst die "aktuelle" \System32\DRIVERS\mrxsmb20.sys
(rechte Maustaste, siehe Eigenschaften / Details / Datum und Version )
macht das auch mit allen anderen, also am besten 1x "suchen" und dann in der Liste jeweils rechte Maustaste.
wenn man sich das Datum und die Versions Nummern ansieht ergibt sich ( für mich ) folgendes Bild
In der KB2028965 geht es ja um das MRXSMB20.SYS "Problem".
Anfang des Jahres 2010, im Februar, bekamen wir die v20655 Version anstelle der v16385.
diese hatten nun die Parameter, welche Andreas Herdt beschrieben hat http://technet.microsoft.com/en-us/libr ... 10%29.aspx
und "wirken" natürlich nur wenn die Function der v20xxx diese "aufrufen" !
inzwischen hatte M$ "reagiert" und "tauschte" die v20655 wieder gegen eine v16539 aus, man beachte das Datum ( in den Eigenschaften/Detail, nicht Festplatte)
es folgte noch, im Juni 2010, das update auf die v16562.
Im Juli 2010 macht M$ dann mit dem "Hotfix" einen weiteren Versuch mit der v20xxx Version welche ja erst die neuen "Futures" hat !
"Problem" und Registry Patches oder der "Hotfix" beziehen sich also nur auf die v20xxx Version wobei die "aktive" sein muss.
Service Pack 1
Die "RC" ist ja nun raus und man wird wohl behaupten können das die v20xxx Version in Zukunft vorhanden sein wird.
Der Link in der Excel Tabelle führt nun zu http://support.microsoft.com/kb/2028965
ich empfehle immer erst die "original" englische Version zu lesen und dann erst auf die deutsche "Übersetzung" bei Bedarf umzuschalten !
nachdem das XP "Network Topology Responder Protocol Driver for NDIS 6" Problem schon vorgezogen wurde
möchte ich wieder zum Redirector MRXSMB20.SYS kommen.
bei eine "frischen" Win7 Demo Installation und den Updates (51 Hotfix +1 Netzwerkkarte)
hat man 4x MRXSMB20.SYS auf dem PC.
sehen wir und die doch mal "genauer" an, erst die "aktuelle" \System32\DRIVERS\mrxsmb20.sys
(rechte Maustaste, siehe Eigenschaften / Details / Datum und Version )
macht das auch mit allen anderen, also am besten 1x "suchen" und dann in der Liste jeweils rechte Maustaste.
wenn man sich das Datum und die Versions Nummern ansieht ergibt sich ( für mich ) folgendes Bild
In der KB2028965 geht es ja um das MRXSMB20.SYS "Problem".
Anfang des Jahres 2010, im Februar, bekamen wir die v20655 Version anstelle der v16385.
diese hatten nun die Parameter, welche Andreas Herdt beschrieben hat http://technet.microsoft.com/en-us/libr ... 10%29.aspx
und "wirken" natürlich nur wenn die Function der v20xxx diese "aufrufen" !
inzwischen hatte M$ "reagiert" und "tauschte" die v20655 wieder gegen eine v16539 aus, man beachte das Datum ( in den Eigenschaften/Detail, nicht Festplatte)
es folgte noch, im Juni 2010, das update auf die v16562.
Im Juli 2010 macht M$ dann mit dem "Hotfix" einen weiteren Versuch mit der v20xxx Version welche ja erst die neuen "Futures" hat !
"Problem" und Registry Patches oder der "Hotfix" beziehen sich also nur auf die v20xxx Version wobei die "aktive" sein muss.
Service Pack 1
Die "RC" ist ja nun raus und man wird wohl behaupten können das die v20xxx Version in Zukunft vorhanden sein wird.
Der Link in der Excel Tabelle führt nun zu http://support.microsoft.com/kb/2028965
ich empfehle immer erst die "original" englische Version zu lesen und dann erst auf die deutsche "Übersetzung" bei Bedarf umzuschalten !
finde ich missverständlich was man nun tun soll ...Registrierungsinformationen
Verwenden Sie den Hotfix in diesem Paket haben Sie keinen keine Änderungen an der Registrierung.
alles klar !!!Registry information
To use the hotfix in this package, you do not have to make any changes to the registry.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
tja da habe ich wohl M$ unterschätzt. statt einer v20xxx ist in der "RC" eine v6.1.7601.17105 enthalten.AUGE_OHR hat geschrieben:Service Pack 1
Die "RC" ist ja nun raus und man wird wohl behaupten können das die v20xxx Version in Zukunft vorhanden sein wird.
Der Link in der Excel Tabelle führt nun zu http://support.microsoft.com/kb/2028965
Nun müsste man vergleichen ob die KB2028965 Datei identisch ist mit der "RC" Datei, aber aufgrund der Versions Nummer und der Grösse (94,5Kb) scheint sie mir "anders" zu sein.
egal, erster Eindruck wie schon bei der "beta" : RAM Durchsatz liegt paar Punkte höher und dadurch auch die OnBoard GFK Leistung.
btw. alles bezogen auf die x86 Version
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
betr. Router
ich muss es genauer spezifizieren was ich meine. Mein Telekom Speedport ist nicht IP6 fähig.
an dem Speedport sind aber auch LAN Anschlüsse und zum Windows Update, wofür man kein IP6 braucht, habe ich den PC mit dem Speedport verbunden.
nach dem update, die Kabel waren ja noch im Speedport, habe ich es über die LAN Ports vom Speedport versucht und da ging nichts mit IP6 über die LAN Ports.
also habe ich für die PC-PC Verbindung einen alten 100mBit Switch benutzt und da ging es.
den SpeedPort Router kann man dann an den Switch "direkt" hängen, aber die Lösung mit der 2nd Netzwerkkarte finde ich "sicherer".
ich muss es genauer spezifizieren was ich meine. Mein Telekom Speedport ist nicht IP6 fähig.
an dem Speedport sind aber auch LAN Anschlüsse und zum Windows Update, wofür man kein IP6 braucht, habe ich den PC mit dem Speedport verbunden.
nach dem update, die Kabel waren ja noch im Speedport, habe ich es über die LAN Ports vom Speedport versucht und da ging nichts mit IP6 über die LAN Ports.
also habe ich für die PC-PC Verbindung einen alten 100mBit Switch benutzt und da ging es.
den SpeedPort Router kann man dann an den Switch "direkt" hängen, aber die Lösung mit der 2nd Netzwerkkarte finde ich "sicherer".
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
hi,
so nun habe ich die Win 7 Sp1 "RC" seit 2 Tagen und bin etwas "enttäuscht". Einige der "beta Futures" wurden scheinbar wieder "entfernt"
die uns interessierende MRXSMB20.SYS liegt nun "nur" als 6.1.6071.17105 vor und hat nicht die "Futures" der .20xxx Version, also wirken die "neuen" Parameter nicht.
Einen 8999 habe ich damit noch nicht feststellen können, auch nicht mit XP als Workstation.
die KB2028965 beschreibt ja
es reicht mit 2x PCs um überhaupt zu prüfen ob ein 8999 auftritt und ob alle Datensätze in der DBF sind, aber das sagt noch nichts über das gemeinsame "locking" aus.
im ersten Test wird die DBF angelegt und die Indexe erzeugt.
das ganze passiert 2x EXCLUSIVE und SHARE, man achte auf den Geschwindigkeits Unterschied
Der Code ist für Xbase (ohne ++) gedacht sodass man auch Ergebnisse von "andere" Compiler betrachten kann
!!! bitte zuerst "LOCAL cHost" in euer freigegebenes Verzeichniss ändern !!!der default Wert steht bei 1000 und sollte bei jedem Test erhöht werden um die Effekte besser beobachten zu können.
Da der erste Teil EXCLUSIVE ausgeführt wird kann immer nur 1 Workstation die Application nutzen.
Die zweite Version ist nun dafür gedacht wenn man den 1st Test bestanden hat.
der Test sollte von mindesten 2 Workstationen "gleichzeitig" gefahren werden.wenn es klappt sollte die DBF etwa so aussehen
Auf dem "Server" sollte man nun den Resource Monotor starten und unter Netzwerk nachsehen was da passiert.
geändert : statt 8889 muss es 8999 sein
so nun habe ich die Win 7 Sp1 "RC" seit 2 Tagen und bin etwas "enttäuscht". Einige der "beta Futures" wurden scheinbar wieder "entfernt"
die uns interessierende MRXSMB20.SYS liegt nun "nur" als 6.1.6071.17105 vor und hat nicht die "Futures" der .20xxx Version, also wirken die "neuen" Parameter nicht.
Einen 8999 habe ich damit noch nicht feststellen können, auch nicht mit XP als Workstation.
die KB2028965 beschreibt ja
wobei 2x PCs dann ja nicht reichen ... man braucht 3x PCs (1x Server und 2x Workstation)Ein Problem mit beschädigten Daten tritt auf, wenn mehrere Benutzer Lese- und Schreibvorgänge an der freigegebenen Datei in der Umgebung Smb2
es reicht mit 2x PCs um überhaupt zu prüfen ob ein 8999 auftritt und ob alle Datensätze in der DBF sind, aber das sagt noch nichts über das gemeinsame "locking" aus.
im ersten Test wird die DBF angelegt und die Indexe erzeugt.
das ganze passiert 2x EXCLUSIVE und SHARE, man achte auf den Geschwindigkeits Unterschied
Der Code ist für Xbase (ohne ++) gedacht sodass man auch Ergebnisse von "andere" Compiler betrachten kann
!!! bitte zuerst "LOCAL cHost" in euer freigegebenes Verzeichniss ändern !!!
Code: Alles auswählen
#include "Directry.ch"
#include "common.ch"
#IFDEF __XPP__
#include "DLL.ch"
#ENDIF
PROCEDURE Main(cMax)
*LOCAL cHost := "\\A-pc\_e\0"
LOCAL cHost := "\\A-hp\ALASKA\0\"
LOCAL cFile := "TESTOPS.DBF"
LOCAL cNode := NETNAME()
LOCAL i
LOCAL nRec
LOCAL nStart
LOCAL nStop
LOCAL nper := 0
LOCAL nMax := 1000
DEFAULT cMax TO 1000
IF PCOUNT() > 0
IF VAL(cMax) > 0
nMax := VAL(cMax)
ENDIF
ENDIF
SET DECIMALS TO 4
// clear all Index
AEval( Directory(cHost+"\"+"*.NTX"),{ |a| FERASE( cHost+"\"+a[F_NAME] ) } )
IF .NOT. FILE(cHost+"\"+cFile)
C_TESTOPS(cHost+"\"+cFile)
ENDIF
USE (cHost+"\"+cFile) EXCLUSIVE
IF NetErr()
#IFDEF __XPP__
Msgbox("USE EXCLUSIVE Error")
#ELSE
Alert("USE EXCLUSIVE Error")
#ENDIF
QUIT
ELSE
ZAP
ENDIF
CLS
? "SMB2 Demo, "+LTRIM(STR(nMax,10,0))+" to add records, press any key to start ..."
CreateIndex(cHost)
CLOSE DATABASE
//
// Testtime USE
//
nStart := SECONDS()
USE (cHost+"\"+cFile) EXCLUSIVE
IF NetErr()
#IFDEF __XPP__
Msgbox("USE EXCLUSIVE Error")
#ELSE
Alert("USE EXCLUSIVE Error")
#ENDIF
QUIT
ELSE
SET INDEX TO (cHost+"\"+"TESTOPS1.NTX"),;
(cHost+"\"+"TESTOPS2.NTX"),;
(cHost+"\"+"TESTOPS3.NTX"),;
(cHost+"\"+"TESTOPS4.NTX")
ENDIF
nStop := SECONDS()-nStart
? "USE Sec."+LTRIM(STR(nStop))
? ""
IF nStop > 1
? "if longer than 1sec. use http://support.microsoft.com/kb/150384"
ENDIF
//
// Test APPEND BLANK
//
? "starte DBF APPEND BLANK EXCLUSIVE, please wait ..."
nStart := SECONDS()
FOR i := 1 TO nMax
APPEND BLANK
REPLACE TESTSTRING WITH Replicate("A",50)
REPLACE TESTNUM WITH RECNO()
REPLACE TESTDATE WITH DATE()
REPLACE TESTTIME WITH TIME()
REPLACE TESTNODE WITH cNode
IF (i % 100) == 0
nStop := SECONDS()-nStart
nper := nStop/i
@ 10,0 Say "Prozent "+LTRIM(STR(i/100,10,0 ))+"% per Record "+LTRIM(STR(nper))+" Sec."
ENDIF
NEXT
nStop := SECONDS()-nStart
? "APPEND BLANK Sec."+LTRIM(STR(nStop))
? ""
nper := nStop/nMax
? "per Record "+ LTRIM(STR(nper))+" Sec."
IF nper > 0.04
IF nper > 0.5
? "you have a BIG Performance Problem"
ELSE
? "if Time are to long use http://support.microsoft.com/kb/825433"
ENDIF
ENDIF 3
? ""
? nRec := LASTREC(), RECCOUNT()
SET ORDER TO 2
SEEK(nMax)
IF FOUND()
? "FOUND "+LTRIM(STR(RECNO()))
ELSE
? "this is BAD"
ENDIF
ZAP
CLOSE DATABASE
WAIT "is it "+LTRIM(STR(nMax))+" ? press any key ..."
CLS
? "USE SHARE, "+LTRIM(STR(nMax,10,0))+" to add records, please wait ..."
nStart := SECONDS()
USE (cHost+"\"+cFile) SHARE
IF NetErr()
#IFDEF __XPP__
Msgbox("USE SHARE Error")
#ELSE
Alert("USE SHARE Error")
#ENDIF
QUIT
ELSE
SET INDEX TO (cHost+"\"+"TESTOPS1.NTX"),;
(cHost+"\"+"TESTOPS2.NTX"),;
(cHost+"\"+"TESTOPS3.NTX"),;
(cHost+"\"+"TESTOPS4.NTX")
ENDIF
nStop := SECONDS()-nStart
? "USE Sec."+LTRIM(STR(nStop))
? ""
IF nStop > 1
? "if longer than 1sec. use http://support.microsoft.com/kb/150384"
ENDIF
//
// Test APPEND BLANK
//
? "starte DBF APPEND BLANK SHARE, please wait ..."
nStart := SECONDS()
FOR i := 1 TO nMax
* APPEND BLANK
TESTOPS->( DbAppend() )
IF NetErr()
ELSE
nRec := TESTOPS->(RECNO())
IF TESTOPS->(DbRLock(nRec))
REPLACE TESTOPS->TESTSTRING WITH Replicate("A",50)
REPLACE TESTOPS->TESTNUM WITH RECNO()
REPLACE TESTOPS->TESTDATE WITH DATE()
REPLACE TESTOPS->TESTTIME WITH TIME()
REPLACE TESTOPS->TESTNODE WITH cNode
TESTOPS->(DbRUnlock(nRec))
ELSE
ENDIF
IF (i % (nMax/100)) == 0
nStop := SECONDS()-nStart
nper := nStop/i
@ 10,0 Say "Prozent "+LTRIM(STR(i/(nMax/100),10,0 ))+"% per Record "+LTRIM(STR(nper))+" Sec."
ENDIF
ENDIF
NEXT
nStop := SECONDS()-nStart
? "APPEND BLANK Sec."+LTRIM(STR( nStop ))
? ""
nper := nStop/nMax
? "per Record "+ LTRIM(STR(nper))+" Sec."
IF nper > 0.04
IF nper > 0.5
? "you have a BIG Performance Problem"
ELSE
? "if Time are to long use http://support.microsoft.com/kb/825433"
ENDIF
ENDIF
? ""
? nRec := LASTREC(), RECCOUNT()
SET ORDER TO 2
SEEK(nMax)
IF FOUND()
? "FOUND "+LTRIM(STR( RECNO() ))
ELSE
? "this is BAD, you have a OPs Locking Problem"
ENDIF
CLOSE DATABASE
? "create new Index"
AEval( Directory(cHost+"\"+"*.NTX"),{ |a| FERASE( cHost+"\"+a[F_NAME] ) } )
USE (cHost+"\"+cFile) EXCLUSIVE
IF NetErr()
#IFDEF __XPP__
Msgbox("USE EXCLUSIVE Error")
#ELSE
Alert("USE EXCLUSIVE Error")
#ENDIF
QUIT
ENDIF
? nRec := LASTREC(), RECCOUNT()
WAIT "is it "+LTRIM(STR(nMax))+"? press any key ..."
CreateIndex(cHost)
SET INDEX TO (cHost+"\"+"TESTOPS1.NTX"),;
(cHost+"\"+"TESTOPS2.NTX"),;
(cHost+"\"+"TESTOPS3.NTX"),;
(cHost+"\"+"TESTOPS4.NTX")
SET ORDER TO 2
SEEK(nMax)
IF FOUND()
? "FOUND "+LTRIM(STR( RECNO() ))
ELSE
? "this is BAD, you have a OPs Locking Problem"
ENDIF
CLOSE DATABASE
IF (nRec % nMax) == 0
WAIT "is it "+LTRIM(STR(nMax))+"? press any key ..."
ELSE
WAIT "seems NOT all Records in DBF, only "+LTRIM(STR(nRec))+" ? press any key ..."
ENDIF
CLS
RETURN
PROCEDURE CreateIndex(cHost)
LOCAL nStart
nStart := SECONDS()
INDEX ON TESTOPS->TESTSTRING TO (cHost+"\"+"TESTOPS1.NTX")
CLOSE INDEX
? "TESTOPS1.NTX Sec."+LTRIM(STR(SECONDS()-nStart))
nStart := SECONDS()
INDEX ON TESTOPS->TESTNUM TO (cHost+"\"+"TESTOPS2.NTX")
CLOSE INDEX
? "TESTOPS2.NTX Sec."+LTRIM(STR(SECONDS()-nStart))
nStart := SECONDS()
INDEX ON TESTOPS->TESTDATE TO (cHost+"\"+"TESTOPS3.NTX")
CLOSE INDEX
? "TESTOPS3.NTX Sec."+LTRIM(STR(SECONDS()-nStart))
nStart := SECONDS()
INDEX ON TESTOPS->TESTTIME TO (cHost+"\"+"TESTOPS4.NTX")
CLOSE INDEX
? "TESTOPS4.NTX Sec."+LTRIM(STR(SECONDS()-nStart))
RETURN
FUNCTION C_TESTOPS(datei,alias,id)
LOCAL p,field_list:={}
IF VALTYPE(datei)!="C"
datei="TESTOPS.DBF"
ENDIF
IF VALTYPE(alias)!="C"
p=AT(".",datei)
alias=IF(p>0,SUBSTR(datei,1,p-1),datei)
ENDIF
IF valtype(id)!="N"
id=0
ENDIF
SELECT (id)
IF !FILE(datei)
AADD(field_list,{"TESTSTRING","C",50,0})
AADD(field_list,{"TESTNUM" ,"N",10,0})
AADD(field_list,{"TESTDATE" ,"D", 8,0})
AADD(field_list,{"TESTTIME" ,"C", 8,0})
AADD(field_list,{"TESTNODE" ,"C",10,0})
DBCREATE(datei,field_list)
ENDIF
USE (datei) ALIAS (alias)
RETURN(.t.)
#IFDEF __XPP__
FUNCTION NETNAME()
LOCAL nDll, cName := SPACE( 255 ), nSize := 255, cReturn := ''
nDll := DllLoad( "kernel32.dll" )
IF nDll <> 0
IF !EMPTY( DllCall( nDll, DLL_STDCALL, "GetComputerNameA", @cName, @nSize ) )
cReturn := LEFT( cName, nSize )
ENDIF
DllUnload( nDll )
ENDIF
RETURN ( cReturn )
#ELSE
// Clipper v5.2e does have NetName()
#ENDIF
Da der erste Teil EXCLUSIVE ausgeführt wird kann immer nur 1 Workstation die Application nutzen.
Die zweite Version ist nun dafür gedacht wenn man den 1st Test bestanden hat.
der Test sollte von mindesten 2 Workstationen "gleichzeitig" gefahren werden.
Code: Alles auswählen
#include "Directry.ch"
#include "common.ch"
#IFDEF __XPP__
#include "DLL.ch"
#ENDIF
PROCEDURE Main(cMax)
*LOCAL cHost := "\\A-pc\_e\0"
LOCAL cHost := "\\A-hp\ALASKA\0\"
LOCAL cFile := "TESTOPS.DBF"
LOCAL cNode := NETNAME()
LOCAL i
LOCAL nStart
LOCAL nStop
LOCAL nRec
LOCAL nper := 0
LOCAL nMax := 1000
LOCAL nLast := 0
DEFAULT cMax TO 1000
IF PCOUNT() > 0
IF VAL(cMax) > 0
nMax := VAL(cMax)
ENDIF
ENDIF
SET DECIMALS TO 4
IF .NOT. FILE(cHost+"\"+cFile)
#IFDEF __XPP__
MSGBOX("File not found")
#ELSE
Alert("File not found")
#ENDIF
QUIT
ENDIF
CLS
? "SMB2 Demo, "+LTRIM(STR(nMax,10,0))+" to add records, please wait ..."
//
// Testtime USE
//
nStart := SECONDS()
USE (cHost+"\"+cFile) SHARE
IF NetErr()
#IFDEF __XPP__
Msgbox("USE SHARE Error")
#ELSE
Alert("USE SHARE Error")
#ENDIF
QUIT
ELSE
SET INDEX TO (cHost+"\"+"TESTOPS1.NTX"),;
(cHost+"\"+"TESTOPS2.NTX"),;
(cHost+"\"+"TESTOPS3.NTX"),;
(cHost+"\"+"TESTOPS4.NTX")
ENDIF
nStop := SECONDS()-nStart
? "USE Sec."+LTRIM(STR(nStop))
? ""
IF nStop > 1
? "if longer than 1sec. use http://support.microsoft.com/kb/150384"
ENDIF
nLast := TESTOPS->( LASTREC() )
//
// Test APPEND BLANK
//
? "starte DBF APPEND BLANK, please wait ..."
nStart := SECONDS()
FOR i := 1 TO nMax
* APPEND BLANK
TESTOPS->( DbAppend() )
IF NetErr()
ELSE
nRec := TESTOPS->(RECNO())
IF TESTOPS->(DbRLock(nRec))
REPLACE TESTOPS->TESTSTRING WITH Replicate("A",50)
REPLACE TESTOPS->TESTNUM WITH RECNO()
REPLACE TESTOPS->TESTDATE WITH DATE()
REPLACE TESTOPS->TESTTIME WITH TIME()
REPLACE TESTOPS->TESTNODE WITH cNode
TESTOPS->(DbRUnlock(nRec))
ELSE
ENDIF
IF (i % (nMax/100)) == 0
nStop := SECONDS()-nStart
nper := nStop/i
@ 7,0 Say "Prozent "+LTRIM(STR(i/(nMax/100),10,0 ))+"% per Record "+LTRIM(STR(nper))+" Sec."
ENDIF
ENDIF
NEXT
nStop := SECONDS()-nStart
? "APPEND BLANK Sec."+LTRIM(STR( nStop ))
? ""
nper := nStop/nMax
? "per Record "+ LTRIM(STR(nper))+" Sec."
IF nper > 0.04
IF nper > 0.5
? "you have a BIG Performance Problem"
ELSE
? "if Time are to long use http://support.microsoft.com/kb/825433"
ENDIF
ENDIF
? ""
? nRec := LASTREC(), RECCOUNT()
SET ORDER TO 2
SEEK(nMax+nLast)
IF FOUND()
? "FOUND "+LTRIM(STR( RECNO() ))
ELSE
? "this is BAD, you have a OPs Locking Problem"
ENDIF
CLOSE DATABASE
IF (nRec % (nMax+nLast)) == 0
WAIT "is it "+LTRIM(STR(nRec))+"? press any key ..."
ELSE
WAIT "seems NOT all Records in DBF, only "+LTRIM(STR(nRec))+" ? press any key ..."
ENDIF
CLS
RETURN
#IFDEF __XPP__
FUNCTION NETNAME()
LOCAL nDll, cName := SPACE( 255 ), nSize := 255, cReturn := ''
nDll := DllLoad( "kernel32.dll" )
IF nDll <> 0
IF !EMPTY( DllCall( nDll, DLL_STDCALL, "GetComputerNameA", @cName, @nSize ) )
cReturn := LEFT( cName, nSize )
ENDIF
DllUnload( nDll )
ENDIF
RETURN ( cReturn )
#ELSE
// Clipper v5.2e does have NetName()
#ENDIF
geändert : statt 8889 muss es 8999 sein
Zuletzt geändert von AUGE_OHR am Di, 09. Nov 2010 17:23, insgesamt 1-mal geändert.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
hi,
den Test Source Code habe ich ja "compatible" gehalten damit man ihn auch für Cl*pper & Co nutzen kann.
Wenn ich nun Cl*pper im Windows Netzwerk einsetzte ( 32bit Umgebung ) wird zum "sperren" der "ganz alte" DOS Modus verwendet.
Die "Kommunikation" (nicht "Transport" ) erfolgt dabei über NetBIOS. Als "Transport" Protokoll gab es IPX, SPX, Netbeui etc.
Lasst und mal nur das IP Protokoll betrachten, hier 3 Bilder auf einer XP Stationen die Cl*pper Anwendung gestartet, man sieh eine "gleichmässige" Line. die selbe Anwendung auf dem Win7 PC, man sieht die "Spitzen"
und nun beide zusammen wieder eine "gleichmässige" Line
beachtet das dass 3th Bild auch die "lokalen Port" anzeigt (139 / 455 )
was passiert nun da und warum sind die "Transferraten" so verschieden ?
Das erste Bild zeigt ja Cl*pper von einer XP Station. XP hat MRXSMB.SYS ( SMB1 ) als Redirector
Die Kommunikation erfolgt über Port 139 ( Session Service ), das "sperren" erfolgt hierbei "regelmässig".
Das zweite Bild zeit Cl*pper von eine Win7 Station. Win7 hat MRXSMB.SYS ( SMB1 ) und auch MRXSMB20.SYS ( SMB2 ).
Die Kommunikation erfolgt über Port 445, das sperren erfolgt hierbei "optimiert" d.h. Daten werden "zusammengefasst" wodurch die "Spitzen" entstehen.
Das dritte Bild zeigt nun XP und Win7 wenn beide jeweils die Cl*pper Anwendung gestartet haben.
Man kann "sehen" wie nun die Win7 Station "runter-schaltet", kaum "Spitzen" zu "sehen".
ok nun haben wir die Bilder gesehen, aber was sagen die Zahlen ?
Ich habe ja im Test Programm, mit SECONDS(), eine Zeitmessung eingebaut.
Die ermittelten Zeiten sind zwar Hardware abhängig, aber die Effekte sind viel grösser als jede Hardware.
XP, 3Ghz HT, 2GB mit Cl*pper 0.01 Sec./Rec womit sich ca. 6-11Mbit ergibt
Win7, 2.8GHz, 1GB mit Cl*pper 0.0015 Sec./Rec also ein Faktor 10 !!!
beides bezieht sich nun auf den SHARED Modus, den wir im Netzwerk ja brauchen.
Gegen Test : Beim Test Programm "anlegen" der DBF verwende ich ja EXCLUSIVE und SHARED.
vergleicht die beiden Zeiten mal mit der o.g. wobei auch ca. der Faktor 10 raus kommen sollte.
und Bild 3 wo ja beide arbeiten ?
beide 0.02 - 0.05 (je nach Datenmenge) d.h. der "langsamste" PC zwingt alle anderen auf sein Niveau "runter-zuschalten" und erzeugen eine "Dauerlast" im Netzwerk. Da Win7 auch noch ständig versucht "hoch-zuschalten", was aber blockiert wird, entsteht ein zusätzlicher Overhead wie man bei "Empfangenen" Byte erkennen kann.
den Test Source Code habe ich ja "compatible" gehalten damit man ihn auch für Cl*pper & Co nutzen kann.
Wenn ich nun Cl*pper im Windows Netzwerk einsetzte ( 32bit Umgebung ) wird zum "sperren" der "ganz alte" DOS Modus verwendet.
Die "Kommunikation" (nicht "Transport" ) erfolgt dabei über NetBIOS. Als "Transport" Protokoll gab es IPX, SPX, Netbeui etc.
Lasst und mal nur das IP Protokoll betrachten, hier 3 Bilder auf einer XP Stationen die Cl*pper Anwendung gestartet, man sieh eine "gleichmässige" Line. die selbe Anwendung auf dem Win7 PC, man sieht die "Spitzen"
und nun beide zusammen wieder eine "gleichmässige" Line
beachtet das dass 3th Bild auch die "lokalen Port" anzeigt (139 / 455 )
was passiert nun da und warum sind die "Transferraten" so verschieden ?
Das erste Bild zeigt ja Cl*pper von einer XP Station. XP hat MRXSMB.SYS ( SMB1 ) als Redirector
Die Kommunikation erfolgt über Port 139 ( Session Service ), das "sperren" erfolgt hierbei "regelmässig".
Das zweite Bild zeit Cl*pper von eine Win7 Station. Win7 hat MRXSMB.SYS ( SMB1 ) und auch MRXSMB20.SYS ( SMB2 ).
Die Kommunikation erfolgt über Port 445, das sperren erfolgt hierbei "optimiert" d.h. Daten werden "zusammengefasst" wodurch die "Spitzen" entstehen.
Das dritte Bild zeigt nun XP und Win7 wenn beide jeweils die Cl*pper Anwendung gestartet haben.
Man kann "sehen" wie nun die Win7 Station "runter-schaltet", kaum "Spitzen" zu "sehen".
ok nun haben wir die Bilder gesehen, aber was sagen die Zahlen ?
Ich habe ja im Test Programm, mit SECONDS(), eine Zeitmessung eingebaut.
Die ermittelten Zeiten sind zwar Hardware abhängig, aber die Effekte sind viel grösser als jede Hardware.
XP, 3Ghz HT, 2GB mit Cl*pper 0.01 Sec./Rec womit sich ca. 6-11Mbit ergibt
Win7, 2.8GHz, 1GB mit Cl*pper 0.0015 Sec./Rec also ein Faktor 10 !!!
beides bezieht sich nun auf den SHARED Modus, den wir im Netzwerk ja brauchen.
Gegen Test : Beim Test Programm "anlegen" der DBF verwende ich ja EXCLUSIVE und SHARED.
vergleicht die beiden Zeiten mal mit der o.g. wobei auch ca. der Faktor 10 raus kommen sollte.
und Bild 3 wo ja beide arbeiten ?
beide 0.02 - 0.05 (je nach Datenmenge) d.h. der "langsamste" PC zwingt alle anderen auf sein Niveau "runter-zuschalten" und erzeugen eine "Dauerlast" im Netzwerk. Da Win7 auch noch ständig versucht "hoch-zuschalten", was aber blockiert wird, entsteht ein zusätzlicher Overhead wie man bei "Empfangenen" Byte erkennen kann.
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
so hier nun 3 Bilder mit Xbase++
und nun wieder beider zusammen es passiert also genau das selbe mit Xbase++ ... nur die gemessenen "Lock" Zeiten ...
XP Workstation mit Xbase++
Win7 Workstation mit Xbase++und nun wieder beider zusammen es passiert also genau das selbe mit Xbase++ ... nur die gemessenen "Lock" Zeiten ...
gruss by OHR
Jimmy
Jimmy
- AUGE_OHR
- Marvin
- Beiträge: 12910
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Datenverlust unter Windows 7
nun möchte ich noch 2 Bilder anhängen
Clipper Xbase++ was man bei beiden sehen kann : es wird hier auch von Win7 der Port 139 benutzt.
btw. wer sich jetzt nun das Xbase++ doch "schneller" sei ( laut Anzeige ...) vergleicht doch mal die "Lock" Zeiten !!!
vielmehr ist es der "Müll" was das Netzwerk belastet, die Stopuhr "beweist" es.
Frage : was hab ich wohl hier im letzten Fall gemacht ?
Clipper Xbase++ was man bei beiden sehen kann : es wird hier auch von Win7 der Port 139 benutzt.
btw. wer sich jetzt nun das Xbase++ doch "schneller" sei ( laut Anzeige ...) vergleicht doch mal die "Lock" Zeiten !!!
vielmehr ist es der "Müll" was das Netzwerk belastet, die Stopuhr "beweist" es.
Frage : was hab ich wohl hier im letzten Fall gemacht ?
gruss by OHR
Jimmy
Jimmy
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2828
- Registriert: Fr, 10. Feb 2006 9:51
- Wohnort: Aachen
- Hat sich bedankt: 259 Mal
- Danksagung erhalten: 12 Mal
- Kontaktdaten:
Re: Datenverlust unter Windows 7
Hallo Markus,
vielen Dank für Deine hilfreiche Information!
Uli
vielen Dank für Deine hilfreiche Information!
Uli
-------
Mitglied XuG Cologne
Mitglied XuG Osnabrück
Mitglied XuG Cologne
Mitglied XuG Osnabrück