6
Verzeichnis, das an einen symbolischen Link auf eine Netzwerkfreigabe erinnert, aber keiner zu sein scheint
Hallo,
auf einem Serverrechner "CPROD" (Windows Server 2008 R2 Standard) sehe ich als loklaer Administrator auf Laufwerk X: ein Verzeichnis "FREI".
Das gehört da fachlich nicht hin. Innerhalb des Verzeichnisses "FREI" sehe ich Verzeichnisse und Dateien, die auf einem anderen Serverrechner (Windows 2012 R2 Standard) "CFILES" auf einer Freigabe liegen ("\\CFILES\FREI"). Es sind aber keine Kopien, sondern es handelt sich tatsächlich um die Dateien aus der Freigabe FREI von CFREI.
Nun mag man an einen symbolischen Link denken. Aber ich erkenne keine Hinweise darauf. Im Explorer sieht das Verzeichnissymbol des Verzeichnisses X:\FREI genauso aus wie für die die anderen Verzeichnisse. Da ist kein Pfeil. Ich habe CMD gestartet. Der Befehl DIR listet den Verzeichnisnamen wie alle anderen. Der Befehl DIR /a:l liefert "Datei nicht gefunden".
Einen symbolischen Link kann man ja anscheinend einfach löschen, ohne Auswirkung auf die Dateien, auf welche der Link verweist.
Aber ich traue mich nicht, X:\FREI zu löschen, solange ich nicht sicher bin, dass es wirklich ein symbolischer Link ist. Die Link-Eigenschaft wird mir nirgends angezeigt.
Was kann denn das bitte sonst noch sein?
Danke und Gruß
Genghis
auf einem Serverrechner "CPROD" (Windows Server 2008 R2 Standard) sehe ich als loklaer Administrator auf Laufwerk X: ein Verzeichnis "FREI".
Das gehört da fachlich nicht hin. Innerhalb des Verzeichnisses "FREI" sehe ich Verzeichnisse und Dateien, die auf einem anderen Serverrechner (Windows 2012 R2 Standard) "CFILES" auf einer Freigabe liegen ("\\CFILES\FREI"). Es sind aber keine Kopien, sondern es handelt sich tatsächlich um die Dateien aus der Freigabe FREI von CFREI.
Nun mag man an einen symbolischen Link denken. Aber ich erkenne keine Hinweise darauf. Im Explorer sieht das Verzeichnissymbol des Verzeichnisses X:\FREI genauso aus wie für die die anderen Verzeichnisse. Da ist kein Pfeil. Ich habe CMD gestartet. Der Befehl DIR listet den Verzeichnisnamen wie alle anderen. Der Befehl DIR /a:l liefert "Datei nicht gefunden".
Einen symbolischen Link kann man ja anscheinend einfach löschen, ohne Auswirkung auf die Dateien, auf welche der Link verweist.
Aber ich traue mich nicht, X:\FREI zu löschen, solange ich nicht sicher bin, dass es wirklich ein symbolischer Link ist. Die Link-Eigenschaft wird mir nirgends angezeigt.
Was kann denn das bitte sonst noch sein?
Danke und Gruß
Genghis
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 263952
Url: https://administrator.de/contentid/263952
Ausgedruckt am: 04.11.2024 um 22:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
kann auch ein Junction-Point sein? Am besten mal prüfen.
http://www.rekenwonder.com/linkmagic.htm
MfG Andreas
kann auch ein Junction-Point sein? Am besten mal prüfen.
http://www.rekenwonder.com/linkmagic.htm
MfG Andreas
iscsi target als netzlaufwerk?
Danke für den Hinweis. Die Software habe ich installiert und damit nach Junction Point gesucht.
Aber wenn ich das richtig verstanden habe, funktioniert nach nur mit Verzeichnissen (und vielleicht Dateien) auf dem gleichen lokalen Rechner, jedoch nicht mit Netzwerkfreigaben von anderen Rechnern.
Das Programm hat zahlreiche Junction Points und einen symbolischen Link gefunden. Der Ordner X:\FREI gehörte aber nicht dazu.
Gruß
Genghis
Aber wenn ich das richtig verstanden habe, funktioniert nach nur mit Verzeichnissen (und vielleicht Dateien) auf dem gleichen lokalen Rechner, jedoch nicht mit Netzwerkfreigaben von anderen Rechnern.
Das Programm hat zahlreiche Junction Points und einen symbolischen Link gefunden. Der Ordner X:\FREI gehörte aber nicht dazu.
Gruß
Genghis
Danke, interessanter Hinweis. iSCSI würde wohl vom Anwendungsgebiet passen.
Wie kann ich herausfinden, ob es das ist? Auf beiden fraglichen Rechnern habe ich einen iSCSI Initiator gestartet und jeweild die Meldung erhalten, dass der Dienst nicht läuft. Ich habe ihn auch nicht gestartet. Ich konnte dort nicht erkennen, wie man vorhandene iSCSI-Beziehungen aufspürt. Bei https://technet.microsoft.com/en-us/library/cc731395.aspx (wo ich nicht alles verstehe) steht, wie man welche erstellt, aber nicht, wie man welche sucht.
Zwei Punkte sprechen gegen iSCSI
1) Anscheinend muss das Target ein komplettes Laufwerk sein. \\CFREI\\FREI ist aber eine Freigabe eines Unterverzeichnisses von Laufwerk D: des Rechners CFREI.
2) Ohne laufenden iSCSI-Initiator scheint iSCSI nicht zu funktionieren. Der läuft aber nicht.
Gruß
Genghis
Wie kann ich herausfinden, ob es das ist? Auf beiden fraglichen Rechnern habe ich einen iSCSI Initiator gestartet und jeweild die Meldung erhalten, dass der Dienst nicht läuft. Ich habe ihn auch nicht gestartet. Ich konnte dort nicht erkennen, wie man vorhandene iSCSI-Beziehungen aufspürt. Bei https://technet.microsoft.com/en-us/library/cc731395.aspx (wo ich nicht alles verstehe) steht, wie man welche erstellt, aber nicht, wie man welche sucht.
Zwei Punkte sprechen gegen iSCSI
1) Anscheinend muss das Target ein komplettes Laufwerk sein. \\CFREI\\FREI ist aber eine Freigabe eines Unterverzeichnisses von Laufwerk D: des Rechners CFREI.
2) Ohne laufenden iSCSI-Initiator scheint iSCSI nicht zu funktionieren. Der läuft aber nicht.
Gruß
Genghis
das ist korrekt, du kannst in der Datenträgerverwaltung ggf. nähere Informationen einholen.
Die Lösung ist DFS.
Über den Weg eines verteilten Dateisystems wurden die Dateien eines abzuschaltenden Fileserverrechners zunächst auf den nicht zu ersetzenden Serverrechner CPROD repliziert. Dann ist der alte Fileserverrechner abgeschaltet und der neue CFREI in Betrieb genommen worden. Seitdem erstreckt sich das verteilte Dateisystem auf CPROD und CFREI.
Meine Angabe "Es sind aber keine Kopien, sondern es handelt sich tatsächlich um die Dateien aus der Freigabe FREI von CFREI" war eine falsche Annahme, weil ich festgestellt habe, dass die Dateien real sind, ich aber auf eine laufende Synchronisation nicht gekommen bin.
Zweck des DFS war es, die Dateien vom alten auf den neuen Fileserver zu migrieren, ohne dabei die Dateiattribute (insbesondere Datum/Uhrzeit) zu verändern.
Nur hat man anscheinend vergessen, die Replikation und das DFS insgesamt wieder abzuschalten und die Dateien auf CPROD zu löschen.
Gruß
Genghis
Über den Weg eines verteilten Dateisystems wurden die Dateien eines abzuschaltenden Fileserverrechners zunächst auf den nicht zu ersetzenden Serverrechner CPROD repliziert. Dann ist der alte Fileserverrechner abgeschaltet und der neue CFREI in Betrieb genommen worden. Seitdem erstreckt sich das verteilte Dateisystem auf CPROD und CFREI.
Meine Angabe "Es sind aber keine Kopien, sondern es handelt sich tatsächlich um die Dateien aus der Freigabe FREI von CFREI" war eine falsche Annahme, weil ich festgestellt habe, dass die Dateien real sind, ich aber auf eine laufende Synchronisation nicht gekommen bin.
Zweck des DFS war es, die Dateien vom alten auf den neuen Fileserver zu migrieren, ohne dabei die Dateiattribute (insbesondere Datum/Uhrzeit) zu verändern.
Nur hat man anscheinend vergessen, die Replikation und das DFS insgesamt wieder abzuschalten und die Dateien auf CPROD zu löschen.
Gruß
Genghis
