files mittels datumswert/zeitwert büerprüfen ob identisch

  • VB.NET

Es gibt 25 Antworten in diesem Thema. Der letzte Beitrag () ist von Agita.

    files mittels datumswert/zeitwert büerprüfen ob identisch

    Hey leute :D hab mal nen neues Problem :D

    vllt hängts mit der uhrzeit auch zamm das ich nich weiter komme ka. :D

    hiern kleiner codeabschnitt von mir


    VB.NET-Quellcode

    1. Function FilesEqual(ByVal SrcFi As FileInfo, ByVal TgtFi As FileInfo) As Boolean
    3. Dim TimeEqual As Boolean
    4. If srcdir_ntfs = True And TgtDir_ntfs = True Then
    5. TimeEqual = SrcFi.LastWriteTimeUtc = TgtFi.LastWriteTimeUtc
    6. Else
    8. TimeEqual = DateDiff(DateInterval.Second, SrcFi.LastWriteTimeUtc, _
    9. TgtFi.LastWriteTimeUtc) <= 2
    12. End If
    13. Return TimeEqual
    14. End Function


    is prinzipiell aus codeproject.

    Folgendes Daten will ich mittels Date/Timw vergleichen. Hierbei gibt es 2 Probleme :)

    Problem 1.

    GMT Zeiten. -12 +13 d.h. LastwritetimeUTC funktionnutzen diese funktioniert aber meines wissen unter FAT16/32 nicht sondern nur unter NTFS

    Problem 2.

    Fat daten werden mit einer differenz bis zu 2 Sekunden geschrieben was ich oben so einigermasen scho gelöst habe mit <=2 sprich einziges problem is das UTC GMT zwischen FAT und NTFS

    Ich danke im vorraus

    lg :)

    datsspeed schrieb:

    VB.NET-Quellcode

    1. TimeEqual = SrcFi.LastWriteTimeUtc = TgtFi.LastWriteTimeUtc
    Überprüf nicht die Gleichheit, sondern teste, ob die Difdferenz kleiner als 2 Sekunden ist.
    Manche Server runden die File-Zeiten auf volle 2 Sekunden.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    datsspeed schrieb:

    is prinzipiell aus codeproject.
    kann ich mir nicht vorstellen.

    ich habe noch keine CodeProject-Source gesehen, wo ein Boolean mit True verglichen wird, wo And verwendet wird statt AndAlso, und wo die VB6-Funktion DateDiff() verwendet wird.

    Falls es tatsächlich einen solchen CodeProject-Artikel geben sollte, so ist er vmtl. unter 3 Sternlein geratet - also lass die Finger von dem.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    ErfinderDesRades
    codeproject.com/Articles/37104…ng-the-way-it-should-work

    RodFromGermany
    Mach ich ja da liegt ja nicht das problem falls es nicht beides ntfs dateisysteme sind spring ich ja auf diese zeile

    VB.NET-Quellcode

    1. TimeEqual = DateDiff(DateInterval.Second, SrcFi.LastWriteTimeUtc, _
    2. TgtFi.LastWriteTimeUtc) <= 2

    und die 2 sekunden geschichte is wie gesagt nur bei fat der fall nicht bei ntfs

    petaod
    .LastWriteTimekann ich leider nicht hernehmen bzw is keine perfekte lösung weil man bei lastwirttime die "lastwrittime" vom eigenem system kriegt ... bringt mir aber 0 wenn ich z.b. rechner 1 auf gmt 0 und rechner 2 auf gmt +1 habe weil mir dann alle dateien von rechner 2 als neuer angezeigt werden obwohl sie einfach nur in verschiedenen gmt zeiten abgespeichert wurden. deshlab die .LastWriteTimeUtc
    funktion diese aber nicht unter FAT sondern nur unter NTFS funktioniert weil fat nicht die UTC zeit unterstüzt


    Was ist UTC. zeitzonen.de/faq/was_bedeutet_utc.html


    LG :)

    datsspeed schrieb:

    VB.NET-Quellcode

    1. DateDiff(...)
    Wenn Du 2 DateTime-Objekte voneinander subtrahierst, bekommst Du ein TimeSpan-Objekt als Ergebnis.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    jo, ist peinlich für codeproject. Zwar benutzt er dort wie von mir erwartet AndAlso, und vergleicht auch nicht ein Boolean mit True, aber scheint ihm tatsächlich auch unbekannt zu sein, dass man DateTimes subtrahieren kann, und die sich ergebenden Timespans auch Sekundenbruchteile angeben können (während olle DateDiff nur Ganzzahlen zurückgibt).

    also immer schön böse Funktionen vermeiden ;)

    €: wieso benutzt er nicht die FileInfo-Klasse?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    ka. ich machs ja mit der fileinfo klasse fakt ist wenn ich ntfs habe benutz ich utc und ich bin sorgenfrei :)

    bei fat brauch ich halt nen trick wie ich au sowas wie utc herkriegen könnte

    datsspeed schrieb:

    wie ich au sowas wie utc herkriegen könnte
    Da musst Du iwie an den Ländercode (==> Zeitzone) rankommen und noch wissen, wann da Winter- und Sommerzeit ist.
    Ansonsten sieht es da mau aus.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    datsspeed schrieb:

    kann ich leider nicht rausfinden
    1. Annahme: Diese Datei wurde in Deutschland generiert.
    2. Bekannt: Beginn und Ende der Sommerzeit.
    3. Handwerk: Berechnung der UTC-Zeit aus den angenommenen und bekannten Informationen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    datsspeed schrieb:

    kennst du den unterschied zwischen FAT und NTFS?
    nein.

    Bekomme ich nun eine Antwort auf meine Frage: hast du FileInfo mal im OB angeguckt?
    (ich weiß, ich nerve, aber das könnte ganz einfach und direkt auf die Lösung führen - vielleicht - weil ich kenne ja FAT nicht)
    Jedenfalls muß ausgeschlossen werden, dass du es nicht getan hast.

    ErfinderDesRades
    wieso sollte ich mir die filinfo klasse nicht angeschauen haben? ich hab sie überflogen und dort sind die interessanten funkis lastwrittimeUTC und lastwrittime ohne utc

    msdn.microsoft.com/de-de/libra…leinfo%28v=vs.110%29.aspx

    RodFromGermany annahme 1 is random und nie fast und mir meist unbekannt ^^

    punkt 2 haste recht und punkt 3 reichts wenn jemand nur falsches datum und gmt zeitraum eingestellt hat dann kannste die berechnung in tonne kloppen ^^

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „datsspeed“ ()

    datsspeed schrieb:

    dann kannste die berechnung in tonne kloppen
    Dann solltest Du einfach das FAT-Datum zu Deinem NTFS-Wert machen, genau so, wie das Systgem es bei einem Kopiervorgang macht.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    datsspeed schrieb:

    wieso sollte ich mir die filinfo klasse nicht angeschauen haben?
    weil du nirgends erwähnst, wie sich FileInfo.LastWriteTimeUtc auf FAT verhält: wirft das Fehler, zeigt es falsch an, oder funktionierts vlt. sogar trotzdem richtig?

    das sollte man doch als erstes ausprobieren, odr?

    RodFromGermany das ist ja mein problem :) wenn die fat datei auf ntfs übertragen wird dann wird sie neu angelegt und die fileinfo funkis werden hinzugefügt und generiert mittels lastwritetime und des lastwrittimeutc wird iwie generiert ich weis aber nich wie und genau des muss ich rausfinden ^^ ich kann schlecht 1000dateien imma von fat auf temporär ntfs kopieren um die richtigen datumswerte zu kriegen

    datsspeed schrieb:

    um die richtigen datumswerte zu kriegen
    Und weil die bösen Kopatoren immer die Zeit verstellen, ist nun keine mehr da?
    Mach ein Experiment und verfolge, wie sich diese Zeiten beim Kopieren verhalten und richte dann Dein Programm danach aus.
    Wenn jemand wie auch immer eingreift, hat diese DAtei halt Pech gehabt.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

    ErfinderDesRades
    For two files to be considered equal, they must have identical LastWriteTimeUTCs snd must have identical lengths. They also must match in certain FileAttributes (ReadOnly, Hidden, System, and Encrypted). Note that FilesEqual also determines, for Not Equal Files, if TgtFile is newer than SrcFile. If so, that result is passed back to the caller, which deals with it based on the Overwrite option.


    The question of LastWriteTimeUTCs equality must be based on which file system contains the FileItems. FAT and FAT32 file systems only keep LastWriteTime to an accuracy of 2 seconds. It is rare that a file copied from an NTFS volume to a FAT32 volume will retain the same LastWriteTime. The Windows Shell uses a similar 2 second window when comparing LastWriteTime, so my code is at least that good.


    A further complication, not dealt with by DirMirror, is that FAT and FAT32 file systems do not actually keep LastWriteTimeUTC. Windows derives that value from LastWriteTime according to the Daylight Savings Time rules in force when the information is requested. This last point will result in the (unnecessary) Overwriting
    of many files, at Daylight Savings Time changes. I would like to fix
    this, but Windows XP and before does not keep historical information
    about Daylight Savings Time rules. In fact, I don't think Vista does
    either, though I haven't checked this out fully.
    des steht im beitrag von codeprojekt

    RodFromGermany ja ich könnte fuschen und sagen wenn sekunden nur +-2 bei fat is der rest gleich und die STunden sich nur +-12 bewegen könnte es an der gmt zeit liegen was aber aus meiner sicht ganz und garnich sauber ist ...

    datsspeed schrieb:

    was aber aus meiner sicht ganz und garnich sauber ist ...
    Deswegen sollst Du halt die 3 Annahmen machen.
    Was sagt Dein Chef dazu?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!

Facebook
Telefonspende