[Mike-Ao]

moin leutz.

Kurioses Problem bei neuanlegen einer Datei.

Bevor ich eine neue Datei aus einem eigenen (KEIN ZIP oder so) Archiv als Vorlage extrahiere, prüfe ich ob diese Vorlage schon existiert und nicht verändert wurde.
Eigentlich ist an diesem Code ja nix falsch

&& existierende und geänderte Druckvorlage speichern?
	Lo_Fso = CreateObject('Scripting.FileSystemObject')
	IF Lo_FSO.FileExists(Lc_File)
		Lo_Fil = Lo_Fso.GetFile(Lc_File)
		IF Lo_Fil.DateCreated < Lo_Fil.DateLastModified
			IF MESSAGEBOX("Änderung speichern", 32+4, "Druckformat wurde geändert") == 6
				.Data_Save(Lc_File)
			ENDIF 
		ENDIF
		Lo_Fso.DeleteFile(FORCEEXT(Lc_File, "*"))
	ENDIF

    IF !Lo_FSO.FileExists(Lc_File)                           && Druckvorlage nochmals bereitstellen 
        SELECT * FROM (.ArchivAlias) INTO TABLE (Lc_File)
    ENDIF

Unmittelbar danach wird diese Datei neu erstellt aber das "Lo_Fil.DateCreated" wird auf die Erstellunszeit der zuvor gelöschten Datei gestellt. das "Lo_Fil.DateLastModified" enspricht aber den Erstellungszeitpunkt.

Optimale Alternativlösung wäre, wenn ich nach dem extrahieren der Datei die beiden Zeitstempel auf den Wert stellen kann, der in meinem Archiv las letzte Speicherung eingetragen ist.

BTW: Ist nicht nur in W11, sondern auch auf W10 getestet

Nachtrag: hab soeben noch paar Tests gemacht
Wenn ich die zu löschende Datei per "DELETE FILE (FORCEEXT(Lc_File, "*")) RECYCLE" lösche, wird auch der Zeitstempel "DateCreated" auf den wert der Ersterstellung gesetzt.
Lösche ich die nun im Papierkorb stehenden Dateien und erstelle die neu, dann stimmt die Erstellungszeit wieder.

Dieser Beitrag wurde von Mike-Ao bearbeitet: 15. August 2024 - 00:48

[Superpeppi]

Dieser Effekt ist mit auch schon öfter aufgefallen.
Ich vermute dass das Absicht sein könnte.
Nehmen wir mal an wir öffnen eine bestehende Text- oder Bilddatei, verändern sie und Speichern das ganze wieder zurück.
In dem Fall möchten wir ja auch das ursprüngliche Erstellungsdatum beibehalten, obwohl beim Speichern der Veränderten Datei die Alte zuerst gelöscht werden muss bevor die Neue geschrieben werden kann.
Verschieben wir die Alte zuerst in den Papierkorb existiert sie ja noch und die Neue ist dann wirklich eine neue Datei mit neuem Erstellungsdatum.
Das ist zumindest die einzige Erklärung die ich für dieses Verhalten habe.

Dieser Beitrag wurde von Superpeppi bearbeitet: 09. September 2024 - 11:25

[Mike-Ao]

Zitat (Superpeppi: 09. September 2024 - 11:24)

obwohl beim Speichern der Veränderten Datei die Alte zuerst gelöscht werden muss bevor die Neue geschrieben werden kann.

Das halte ich aber für einen nicht notwendigen vorgang. Ich öffne eine Datei und lese die darin befindlichen Daten. UNd wenn ich was zu ändern hab, dann weden diese geänderten Daten eben in der geöffenten Date überschrieben. Da muss man keine Datei löschen.
Wär ja ein hammer, wenn ich einen Datensatz innerhalb einer tabelle (DBF) ändere, das diese Datei dann komplett neu geschrieben wird. (>2GB löschen, neu anlegen wegen 5 Buchstaben?)
Sollte beim speichern einer geänderten Datei ein Backup erstellt werden, dann wird die alste Datei VOR dem beschreiben in eben diese xxxx.bak kopiert.

Dieser Beitrag wurde von Mike-Ao bearbeitet: 28. September 2024 - 01:29

[Mike-Ao]

Abgesehen davon, dass meine Anwendung unter W7 etwa gefühlt doppelt so schnell geladen wird als unter W11. Ich hab grad mal getestet und musste feststellen, dass diese falschen Zeitstempel offensichtlich berichtigt wurden.
AAAAAAAber anscheinend kann der explorer nicht mehr sortieren.
Hier mal die gelöschten Dateien in unterschiedlicher Sortierreihenfolge. Beacht bitte den kleinen Pfeil im Header der Spalten.

Hier die Sortierung nach Dateinamen. ich hab diese Datei(en) mehrfach erstellt und wieder gelöscht. Man beachte aber den 1Sek. unterschied bei zwei Vorgängen, wo die Erstellerzeit/Letzteänderungszeit um 23:53 und 23:54 unterschiedlich sind. Was eigentlich nicht sein kann/darf.


Und hier die Sortierung der Anzeige nach LetzeÄnderungsZeit. Die setze ich beim erstellen auf den 01.01.2000, und das OS zeigt die mit 1h früher an. Aber in der Sortierung total fehlerhaft.

[Gispelmob]

Sortiert wird beim 2. Bild nach "Gelöscht am" absteigend und nicht nach Änderungsdatum.

Dieser Beitrag wurde von Gispelmob bearbeitet: 28. September 2024 - 06:58

[Mike-Ao]

ja, aber markiert ist eine ander spalte

[Superpeppi]

Zitat (Mike-Ao: 28. September 2024 - 01:28)

Das halte ich aber für einen nicht notwendigen vorgang. Ich öffne eine Datei und lese die darin befindlichen Daten. UNd wenn ich was zu ändern hab, dann weden diese geänderten Daten eben in der geöffenten Date überschrieben. Da muss man keine Datei löschen.
Wär ja ein hammer, wenn ich einen Datensatz innerhalb einer tabelle (DBF) ändere, das diese Datei dann komplett neu geschrieben wird. (>2GB löschen, neu anlegen wegen 5 Buchstaben?)
Sollte beim speichern einer geänderten Datei ein Backup erstellt werden, dann wird die alste Datei VOR dem beschreiben in eben diese xxxx.bak kopiert.

Und was ist wenn du nur ein Byte mittendrin hinzufügst oder entfernst?
Dann muss alles danach ja verschoben werden.
Wie soll das deiner Meinung nach vonstatten gehen?
Prinzipiell gibt es die Möglichkeit einzelne Teile einer Datei zu ändern, aber beim hinzufügen oder löschen von Teilen funktioniert das nicht und Programmtechnisch aufwendig ist das auch noch.
Daher dürften die meisten Programm das überschreiben der alten Datei bevorzugen.
Man kann sie natürlich auch vorher umbenennen und nach dem schreiben der Neuen erst löschen (aus Programmiere sicht).

Dieser Beitrag wurde von Superpeppi bearbeitet: 29. September 2024 - 13:05

[Mike-Ao]

Zitat (Superpeppi: 29. September 2024 - 13:04)

Und was ist wenn du nur ein Byte mittendrin hinzufügst oder entfernst?
Dann muss alles danach ja verschoben werden.
Wie soll das deiner Meinung nach vonstatten gehen?

Also bislang, und das schon seit DOS-Zeiten, öffne ich diese Datei, und beschreibe die demensprechend ab dem geänderten und/oder eingefügtem Byte. und nicht den 20MB großen Block VOR der änderung.
Dazu gibt es auch wunderbare Funktionen in so allen Programmiersprachen.

Zitat

Sie können fseek und _fseeki64 verwenden, um den Zeiger an einer beliebigen Stelle in einer Datei neu zu positionieren. Der Zeiger kann auch nach dem Ende der Datei positioniert werden. fseek und _fseeki64 löscht den End-of-File-Indikator und negiert die Wirkung aller vorherigen ungetc Aufrufe gegen stream.

https://learn.micros...4?view=msvc-170
Und das gilt jetzt nicht nur für M$, sondern auch in allen anderen Betriebssystemen wie div. Unix'e und sonstigen Mainframes (Dec-PDP..., Tandem-Computers etc.)

[Superpeppi]

Wie schon gesagt, aufwendiger zu Programmieren und wird deshalb auch nur selten genutzt.
Bei Datenbanken wird das so gemacht, da ist es auch egal wo die Daten in der Datei stehen. Man kann sie hinten dranhängen oder in Lücken mittendrin einfügen.
Aber bei normalen Bild-, Text- oder sonstigen Dateien die der Normalnutzer so hat macht das einfache ersetzen der alten Datei mehr Sinn weil einfacher zu Programmieren.

[Mike-Ao]

Zitat (Superpeppi: 30. September 2024 - 11:17)

Wie schon gesagt, aufwendiger zu Programmieren und wird deshalb auch nur selten genutzt.

Naja, Wenn ich bei einer 20MB großen Datei iewas einfügen/löschen muß, dann mach ich diese Änderung über die SEEK-Funktion und schreibe nicht die 20MB neu auf die Platte.

Zitat (Superpeppi: 30. September 2024 - 11:17)

Bei Datenbanken wird das so gemacht, da ist es auch egal wo die Daten in der Datei stehen. Man kann sie hinten dranhängen oder in Lücken mittendrin einfügen.

und genau das ist der springende Punkt.
Wenn ich mein Druckformat aus meiner tabelle herauslade, dann MÜSSEN die beiden Zeitstempel identisch sein, damit ich erkennen kann, ob das Druckformat nur zur Vorlage verwendet wurde, oder ob es geändert/aktualisiert wurde.