Gut ist, dass es jetzt eine Short-Cut-Möglichkeit gibt, die jetzt auch auf meinem S10e bei dem "krummen Pfeil' den Short-Cut auch anlegt - klappt jetzt.
Aber es gibt, seit vermutlich Mitte des Jahres 2023, nach einem Update von TC (oder WLan-Plugin) die Herausforderung, dass plötzlich für mich als Programmierer von Windows aus nicht mehr zuverlässig die Filezeit von Dateien oder Ordner mehr geliefert wird. Bedeutet: Mit der Funktion "GetFileTime()" bekomme ich vielleicht einmal die korrekte Zeit, danach nur noch 0 für "lpLastWriteTime", also des Änderungsdatum. Auch die beiden anderen Zeiten (lpCreationTime und lpLastAccessTime) liefern dann 0.
Win7 oder Win10, alles egal. Auch das neuste Update von TC 3.41 auf 3.42 letztens behob das nicht. WLan-Plugin jetzt 4.3
Ich habe jetzt mal ein share mit einem alten S6 mit Android 7 und TC 2.91, WLan-Plugin 3.2, gesetzt und der arbeitet wie gewohnt, also alle Zeiten werden sauber geliefert, wie es auch bis Anfang letzten Jahres noch mit dem S10e war. Ich weiß nicht, was da an TC (oder am WLan-Plugin?) verändert wurde.
Das blöde an diesem Bug ist, dass er jetzt meine Sync-Routinen meines eigenen Win-Programmes betrifft. Da ja die File-Zeiten genullt sind, sind diese Zeiten daher immer vom 1.1.1601 00:00 Uhr UTC, was nicht wirklich hilfreich ist.
Ich habe bei meiner Programmiersprache alles probiert, da auch die eigenen, internen, normalen FileZeit-Befehle nicht funktionieren. Ich hab daher, wie oben beretis angedeutet, auch die native Aufrufe mit
Code: Select all
hfile = CreateFile(file, GENERIC_READ, 0, Null, OPEN_EXISTING, 0, Null)
ret = GetFileTime(hfile, Null, Null, V:lpLastWriteTime)
Ich weiß mir gerade keinen Rat mehr, wie ich das mit meiner Programmiersprache beheben soll. Das Aufrufen von Filezeit-Befehlen ist/war für mich logischerweise keine Raketen-Technik.
Es geht übrigens nicht um eine Permanent-Verbindung mit festem Pfad, sondern um die schnelle ohne Name+PW über Port 8081