Windows-Clients fragen seit WinXP regelmäßig mit verkürzter Pfad-Angabe unter Weglassung des ersten Slashes nach Server-Resourcen; dies kann dazu führen, dass Verbindungen verloren gehen oder erst gar nicht zu Stande kommen.
Der Hintergrund ist der, dass Microsoft (zu Recht) versucht hat, fehler-tolerant zu arbeiten: Da nicht vorhersehbar ist, ob nicht in Script-Files, Link-Files etc. ein Admin sich vertippt hat und zwei BackSlashes setzte, wo nur einer hingehört, oder umgekehrt nur einen setzte, wo zwei verlangt wären, testet der Windows-Client eben grundsätzlich immer beide Varianten aus: eine wird schon treffen.
Jedoch ist zu beobachten, dass gelegentlich Windows-Client "vergessen", neben der einen Variante auch die andere zu verwenden - und wenn die genutzte Variante zufällig die falsche war, kommt weder eine Namens-/Adress-Auflösung zu Stande, noch ein Zugriff auf die Netzwerk-Resource.
Dies kann zu Verbindungs- und Datenverlust führen.
Zur Auflösung von UNC-Bezeichnern in MAC- bzw. IP-Adressen werden alle verfügbaren Quellen zur Namens-Auflösung heran gezogen, darunter:
Falsche UNC-Namen ziehen einen Rattenschwanz an Namens-/Adress-Auflösung über alle verfügbaren Wege und Protokolle nach sich.
Zentrale Dienste wie LDAP sind stark auf korrekten Umgang mit UNC-Pfaden angewiesen; aber auch schon die simple Tatsache, dass auf dem Active Desktop eines PCs Icons grau (=inaktiv) dargestellt werden, kann auf Fehler in der UNC-Behandlung zurück gehen.
Einer der Treiber, der hier im Windows-Betriebssystem maßgeblich arbeitet, ist MUP.SYS.
Folge: "Das Netzwerk ist langsam" (beliebter Anwender-Mythos).
Mail
an die Online-Redaktion zum aktuellen Thema ("UNC").
