2
Sind LNK-Dateien (Shortlinks) eines W7-64 inkompatibel mit XP-32?
Hallo!
Ich habe hier ein Netzlaufwerk mit ca. 100.000 Dateien und ca. 750.000 Shortlinks (LNK-Dateien) die auf diese Dateien verweisen. Also sowohl die Zieldatei als auch die LNK-Datei liegen auf dem selben NTFS-Laufwerk. Die LNK-Dateien wurden lange Zeit mit XP-32Bit-SP32 in Anwendungsprogrammen oder direkt im Explorer erzeugt. Seit kurzem machen wir das allerdings auch mit W7-64Bit-SP1-Rechnern.
Jetzt stellt sich heraus, das die XP-32-Rechner mit den Links der W7-64-Rechner nichts anfangen können:
Getlink gibt bei LNK-Dateien, die mit W7-64 erzeugt wurden nur einen leeren String zurück.
Dabei fällt auf, dass die LNK-Dateien, die mit W7-64 erzeugt wurden durchweg größer sind als solche, die XP-32 erzeugt. Möglicherweise Unicode.
Hat/kennt jemand einen Funktion für VS2010 mit FW4, die in der Lage ist solche LNK-Dateien unter XP-32 korrekt zu lesen?
Danke fürs lesen, Tussi
PS. Es hat gute Gründe, das wir diese alten LNK-Dateien nutzen und nicht Hardlinks, Softlinks, Symlinks o. ä.
Ich habe hier ein Netzlaufwerk mit ca. 100.000 Dateien und ca. 750.000 Shortlinks (LNK-Dateien) die auf diese Dateien verweisen. Also sowohl die Zieldatei als auch die LNK-Datei liegen auf dem selben NTFS-Laufwerk. Die LNK-Dateien wurden lange Zeit mit XP-32Bit-SP32 in Anwendungsprogrammen oder direkt im Explorer erzeugt. Seit kurzem machen wir das allerdings auch mit W7-64Bit-SP1-Rechnern.
Jetzt stellt sich heraus, das die XP-32-Rechner mit den Links der W7-64-Rechner nichts anfangen können:
Private Function Get_TargetPath(ByVal LinkPathName As String) As String
Dim oShell As New Shell32.Shell
Dim oFolder As Shell32.Folder
Dim oLink As Shell32.ShellLinkObject
Dim sPath = Path.GetDirectoryName(LinkPathName)
Dim sFile = Path.GetFileName(LinkPathName)
Try
oFolder = oShell.NameSpace(sPath)
oLink = oFolder.Items.Item(sFile).GetLink
Return oLink.Path
Catch ex As Exception
Return Nothing
End Try
End FunctionGetlink gibt bei LNK-Dateien, die mit W7-64 erzeugt wurden nur einen leeren String zurück.
Dabei fällt auf, dass die LNK-Dateien, die mit W7-64 erzeugt wurden durchweg größer sind als solche, die XP-32 erzeugt. Möglicherweise Unicode.
Hat/kennt jemand einen Funktion für VS2010 mit FW4, die in der Lage ist solche LNK-Dateien unter XP-32 korrekt zu lesen?
Danke fürs lesen, Tussi
PS. Es hat gute Gründe, das wir diese alten LNK-Dateien nutzen und nicht Hardlinks, Softlinks, Symlinks o. ä.
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: 191342
Url: https://administrator.de/contentid/191342
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
2 Kommentare
Neuester Kommentar
Also prinzipiell kann XP mit Links von Win7 64bit umgehen (zumindestens der Explorer).
Damit sollte eigentlich auch obiger Code es rausbekommen können.
Ich würde mal Zeile 10 und 11 in kleiner Einheiten zerlegen und schauen, ob es nicht eventuell vorher schon Probleme gibt (also on oFolder.Items tatsächlich die Items Auflistung zurückgibt etc.).
Und sicher, daß Du nicht aus irgendwelchen Gründen in die Catch Klausel reinläufst?
Leerer String ist zwar eigentlich was anderes als Nothing aber ich weiß nicht, wie genau hier geschrieben wird.
Damit sollte eigentlich auch obiger Code es rausbekommen können.
Ich würde mal Zeile 10 und 11 in kleiner Einheiten zerlegen und schauen, ob es nicht eventuell vorher schon Probleme gibt (also on oFolder.Items tatsächlich die Items Auflistung zurückgibt etc.).
Und sicher, daß Du nicht aus irgendwelchen Gründen in die Catch Klausel reinläufst?
Leerer String ist zwar eigentlich was anderes als Nothing aber ich weiß nicht, wie genau hier geschrieben wird.
Alle Variablen enthalten gültige Objekte oder Strings.
Selbst olink.Description gibt den korrekten Kommentar wieder, auch olink.WorkingDirectory enthält das korrekte Verzeichnis, nur olink.path enthält tatsächlich einen leeren String (""), nicht nothing.
Der Explorer von XP-32 zeigt im Eigenschaften-Dialog des Links in allen Feldern die richtigen Daten. Die Funktion Get_TargetPath liefert unter W7-64 bislang immer die korrekten Daten. Der Fehler tritt bislang nur unter VB2010 Studio SP1 auf einem XP-32 auf.
Hier ein Link zu einem Screenshot: http://imageshack.us/a/img42/7281/screenshot2rip.jpg
Er zeigt links die Situation unter W7-64 und rechts eine Vbox mit XP-32 und VS2010.
Selbst olink.Description gibt den korrekten Kommentar wieder, auch olink.WorkingDirectory enthält das korrekte Verzeichnis, nur olink.path enthält tatsächlich einen leeren String (""), nicht nothing.
Der Explorer von XP-32 zeigt im Eigenschaften-Dialog des Links in allen Feldern die richtigen Daten. Die Funktion Get_TargetPath liefert unter W7-64 bislang immer die korrekten Daten. Der Fehler tritt bislang nur unter VB2010 Studio SP1 auf einem XP-32 auf.
Hier ein Link zu einem Screenshot: http://imageshack.us/a/img42/7281/screenshot2rip.jpg
Er zeigt links die Situation unter W7-64 und rechts eine Vbox mit XP-32 und VS2010.
