07.11.2022 um 08:14:19 Uhr

3204

Zwei Dateien anhand Dateialter miteinander vergleichen

Hallo,

Ich möchte gern in mein Login-Script eine Abfrage einbauen, die eine lokale Config-Datei aktualisiert, wenn auf dem Netzwerk-Share eine aktuellere liegt.

Beispiel:

Im lokalen Verzeichnis eines Users liegt die Datei Config.xml vom 01.11.2022. Auf dem Netzwerk-Share, auf dem alle User Zugriff haben, liegt ebenso die Datei Config.xml vom 05.11.2022

Die Datei hat immer den identischen Namen. Jetzt brauche ich eine Abfrage, die bei beiden Dateien das Datum der letzten Änderung miteianander vergleicht und die lokale Datei mit der neueren ersetzt, wenn das der Fall ist.

Danke und Grüße

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4531751799

Url: https://administrator.de/forum/zwei-dateien-anhand-dateialter-miteinander-vergleichen-4531751799.html

Ausgedruckt am: 06.04.2025 um 07:04 Uhr

18 Kommentare

Neuester Kommentar

Hallo,

ja geht einfach. Aber wenn es eine kleine File ist kannst du die auch bei jedem Neustart oder Login mit rüberbraten. Da muss man nicht unbedingt Datum vergleichen. copy oder xcopy + Überschreiben und gut ist.

Hier mal Powershell Ausschhnitt. CreationTime vs. LastWriteTime kommt ggf. bei solchen Aktionen noch zu tragen. Aber nicht immer.

Ich würde bei einer Datei aber auf den Abgleichi verzichten.

Function CreateLckFile() { 
            $null = New-Item -ItemType "file" -Path $lckFile;   
            # Fix NTFS Tunnellig
            $(Get-Item -Force $lckFile).CreationTime = $(Get-Item -Force $lckFile).LastWriteTime; 
            }

Function LckTimeDiff() {
            $lckFileCreationTime = $((Get-Item $lckFile).CreationTime)
            $Diffobj = $(Get-Date) - $lckFileCreationTime
            [int]$Script:DiffInMin = [int]$Diffobj.TotalMinutes
            }

Es soll ja eben nicht immer überschireben werden. Unsere entwickler packen gelegentlich neue Config-Files in ein Share. NUR wenn das Configfile neuer ist, als das, was in jedem User-Verzeichnis liegt, soll dieses neue File , das im User-Verzeichnis überschreiben. das darf auf garkeinen Fall bei jedem Login passieren, da sonst ggf. wichtige Einstellungen im Programm beim User verschwunden sind.

Dann sollen sie es woanders hinpacken. Und ein Share nur für "produktiv". Verstehe hier das Problem nicht. Entweder man rollt es aus oder nicht.

Und nach Datum - welches Sprache? Batch, Powershell? Was schwebt Euch vor.....

Es dient ja in diesem Sinne zum Ausrollen durch das login-Script. Es soll sich von jedem user immer das aktuelle File vom Share gezogen werden, wenn dieser sich einloggt.
Das ganze soll per Batch-Script passieren.

Ja aber warum dann nicht immer? Wenn die was ändern, ist eh Datum neuer. Oder setzen die es auf 01.01.1970. Macht für mich keinen Sinn.

Zitat von @MarciMarc85:

Es soll ja eben nicht immer überschireben werden. Unsere entwickler packen gelegentlich neue Config-Files in ein Share. NUR wenn das Configfile neuer ist, als das, was in jedem User-Verzeichnis liegt, soll dieses neue File , das im User-Verzeichnis überschreiben. das darf auf garkeinen Fall bei jedem Login passieren, da sonst ggf. wichtige Einstellungen im Programm beim User verschwunden sind.

Und wenn eine neue Config kommt ist es o.k. die wichtigen Einstellungen verschwinden zu lassen?

Das halte ich jetzt irgendwie für paradox.

wie man mit xcopy nur neuere Dateien kopiert

lks

Also. es handelt sich umn eine Entwicklungsumgebung. dort sicnd 2 Citirx Server mit Anwendungen installiert, die auf 5 Verschiedene Datenbanken in verschiedenenen entwicklungsversionen zeigen. zum testen. diese Config-dateien beinhalten Programmeinstellungen. wenn man das Programm schließt, werden die Änderungen im Programm in diesen Config-Dateien gespeichert. In gewissen Abständen/Teststadien, gibt es von der entwicklung neue /angepasste Default-Configdateien. diese werden in einem zentralen Share abgelegt und sollen, wenn neuer, die alten, lokalen Config-Dateien überschreiben. Das bei jedem User händisch zu machen wäre ja Quatsch. Das kann und soll das Login-Scripzt einfach übernehmen.
Über Sinn und Unsinn diskutieren macht doch garkeinen Sinn. es ist nunmal der aktuelle Anwendungsfall und ich habe lediglich um etwas Hilfe gefragt.

Zitat von @Crusher79:

Ja aber warum dann nicht immer? Wenn die was ändern, ist eh Datum neuer. Oder setzen die es auf 01.01.1970. Macht für mich keinen Sinn.

Die Dateien werden nicht immer geändert. Bevor etwas zum Kunden ausgeliefert wird, aber meist häufiger, als bei allgemeinen Testst. Es kann sein, dass es 3 Wochen keine neue Datei gibt und die Kollegen diverse einstellungen testen und in ihrer Config speichern. dann kann es aber sein, dass es alle 2 Tage eine angepasste Grund-Config gibt, weil was am Programmcode geändert /gefixed wurde.

Zitat von @MarciMarc85:

... dann kann es aber sein, dass es alle 2 Tage eine angepasste Grund-Config gibt, weil was am Programmcode geändert /gefixed wurde.

Und dann solken die Einstellungen überschrieben werden?

Dann nimm xcooy mit passenden Parametern. Das kopiert dann nur, wenn neuer.

lks

Oder auch robocopy, macht das gleiche wie xcopy ... Kopieren nur wenn neuer/geändert.

robocopy "\\server\share" "c:\ziel" config.xml /r:1 /w:2

@Lochkartenstanzer hat schon xcopy erwähnt.

Ich lese deine Posts, aber ich verstehe es immer noch nicht! Ich hab selber mit 4GL Magic uniPaaS/ XPA programmiert und deployed. Da ist alles XML basiert. Daher kenn ich sowas eig. recht gut!

ABER es macht für mich keinen Sinn. Du sprichst über TS und Kunden. Wo sind wir? TS bei euch für die Entwickler oder sind die Kunden dank Cloud o.ä. direkt bei euch eingemietet?

In gewissen Abständen/Teststadien, gibt es von der entwicklung neue /angepasste Default-Configdateien. diese werden in einem zentralen Share abgelegt und sollen, wenn neuer, die alten, lokalen Config-Dateien überschreiben.

OK! Und was wenn das immer passiert? WARUM legen die im Share für das Deployment Zwischenschritte ab?

Sorry, dass ist mir echt zu hoch. Wir validieren doch gar nicht den Inhalt. Dann kann doch auch genauso gut IMMER kopiert werden. Wir hatten damals hunderte von XML files. Die wurden mit robocpoy aktuell gehalten. Mitunter gibt es schon eine Änderung, wenn jemand im GUI nur was aufklappt. Ich kenne wie gesagt sowas.

Du kannst ja auch Namen beim Kopieren ändern! Config_deploy.xml -> Config.xml

XCOPY wäre sowas wie Batch. Wollt ihr PS oder Batch haben?

Ich kenne wie gesagt solche Sauereien. Nicht jeder hat github. Nur wenn die Änderungen schon in der Share liege, woher soll man dann wissen ob es PROD oder TEST ist? Das Skripte würde immer auf neue Dateien los gehen. Genauso gut könnte man dann halt IMMER kopieren.

Irgendwie reden wir aneinander vorbei ....

Zitat von @4400667902:

Oder auch robocopy, macht das gleiche wie xcopy ... Kopieren nur wenn neuer/geändert.

robocopy "\\server\share" "c:\ziel" config.xml /r:1 /w:2

https://www.synology-forum.de/threads/robocopy-sieht-identische-dateien- ...

Mitunter kopiert man auch von Linux Share/ NAS. FFT ist hier dein Freund. Das nochmal als Referenz falls mal Datum nicht eindeutig scheint.

Von Windows zu Windows eher unnötig.

Zitat von @Crusher79:

@Lochkartenstanzer hat schon xcopy erwähnt.

Ich lese deine Posts, aber ich verstehe es immer noch nicht! Ich hab selber mit 4GL Magic uniPaaS/ XPA programmiert und deployed. Da ist alles XML basiert. Daher kenn ich sowas eig. recht gut!

ABER es macht für mich keinen Sinn. Du sprichst über TS und Kunden. Wo sind wir? TS bei euch für die Entwickler oder sind die Kunden dank Cloud o.ä. direkt bei euch eingemietet?

Beispiel:

Entwickler A bekommt per Skript eine aktuelle default-Config.
Diese lädt er in die Software bzw. wird diese Config beim Start der Software automatisch eingelesen. Nun ändert der Entwickler etwas an der Config. Diese Änderung wird in seiner lokalen Config gespeichert. Daran soll auch erstmal nichts geändert werden, damit er (am nächsten Tag, z.B.) wieder daren arbeiten kann mit denselben einstellungen.

Würde das Script bei jedem Login einfach Stumpf die Config aus dem Share wieder laden, hätte entwickler A wieder nur die default-Werte und alle seine Änderungen wären weg.

Wenn eine neue Config im Share bereitgestellt wird, ist das meit nach allgemeinen Anpassungen am Programm. das wissen dann aber auch die entwickler, die die Tests machen. In dem Fall soll natürlich die lokale Config mit der aktualisierten default-Config aus dem Share überschrieben werden.

Natürlich lönnte ich einfach nach Dateinamen filtern und sagen, wenn ein anderer Name im Share ligt, ersetzte die lokale Datei. Aber dann müsste ich die kopierte Date wiieder renamen, da der Name für das Programm festgelegt ist. Zudem müsste ich vorher den Ersteller der neuen Config informieren, dieser jedes Mal einen anderen Namen zu geben, damit sie nicht, wie das original heißt. Das sind mir zu viele Fehlerquellen.

Die Configs der verschiedenen Testumgebungen, liegen in unterschiedlichen Unterordnern im Share. da sollte es keine Probleme geben, ob es sich um Prod oder Test handelt. Zudem ist das ganze eine Kunden-Testumgebung. erst wenn unsere entwicklung sagt, dass alles in der neuen Programmversion passt, wird die finale Config gespeichert und an den Kunden mit ausgeliefert.

Ok verstehe.

Wir hatte das von Hand gemacht. Da keiner den anderern getraut hat

Entwickler sind da eigen....

XCOPY und robocopy via Batch z.B. siehe oben! Reicht das so?

Naja das ist ja noch recht übersichtlich bei dir. Schön ist es ohne github o.ä. Wenn Chef mit alten XML entwickelt hat und bei zusammenführen dann die DataSource nicht mehr passte. Oh ja, ich kenne das. Nicht nur einfach Config, sondern komplett Code in XML gespeichert. Wenn der auseinander läuft....

ich probiere das mal mit xcopy. nur schön wäre es tatsächlich, wenn man die Dateien vorher irgendwie anhand des Dateialters vergleichen könnte. Ich hatte das script erstmal so erstellt, dass es die Dateinamen vergleicht, bei einem Unterscheid, sollte es die Datei aus dem Share kopieren und anschließend die aktuelle Uhrzeit inkl. Namen der geänderten Config ( es gibt mehere Unterschiedliche für das Programm) in eine Textdatei schreiben, um das ganze imme nachvollziehen zu können. Mit ycopy und robocopy hab dich da ja keine Möglichkeiten, oder?

Doch! Log Parameter in Robcopy sagt was passiert...

https://blog.it-koehler.com/en/Archive/3250

/log+:<Pfad_zur_Datei>

Hängt es an eine Log-File an. So hat man immer eine Übersicht, was kopiert wurde. Bzw. wann.

Ach ja, bei PowerShell von oben wird man nicht glücklich! LastWriteTime wäre hier blöd. Da mit Sicherheit die Datei doch beim Arbeiten mit dem Programm nicht nur gelesen, sondern auch geschrieben wird?!?

CreationTime wäre es in deinen Fall wenn ich mich nicht täusche.

Ich würde aber mal robopy nehme.

Nenn die Datei halt doch kurz um und Teste. Oder du nimmst deinen Arbeitsplatz . Dann siehst du ja was passiert.

https://www.nirsoft.net/utils/filedatech.html

Manipulier auch mal damit das Datum. Dann siehst du die Unterschiede ....

https://dns-plus.net/ctime.html

https://www.majorgeeks.com/files/details/change_timestamp.html

ctime ist Moderner! Wenn du die config_test.xml drauf ziehst kannst du alles simulieren! Das sollte reichen ...

confgi_test.xml, damit du die echte nicht zerschießt. Aber dann sollte es auch gut sein. Creation; lastAccessDate etc. alles lässt sich anpassen. Damit kannst du robocopy u.ä. nach Herzen testen.

Vielen Dank für die Hilfe! Hab nun einen relativ übersichtlichen Codeschnipsel, der funktionioert undden ich auf alle anderen Dateien und Stages anwenden kann.

set "trunk_conf_path=R:\rs_client_config"  
set "trunk_log_path=%trunk_conf_path%\config.log"  

if not exist %trunk_log_path% (
echo common.rscfg: >> %trunk_log_path%
)

robocopy "\\lab.local\netlogon\rs_client_config_Trunk" "%trunk_conf_path%" common.rscfg /xo >NUL  

if %errorlevel% gtr 0 (
	echo Common-Config wurde im Userverzeichnis aktualisiert!
	powershell -EP Bypass -C "(gc '%trunk_log_path%') -replace '(^common.rscfg:).*','common.rscfg:  %_timestamp%' | sc '%trunk_log_path%' "  
) else (
	echo Common-Config Trunk ist aktuell!
)