![]() |
[D5] Dateidatum wird falsch gelesen
Hallo,
ich hab gerade festgestellt, daß das Dateidatum falsch ausgelesen wird. und zwar wird das z.B. bei einem (LastChange)Dateidatum vom 1.1.1970 2:22:13 in der Variablen SearchRec.time gar nicht aktualisiert. Es wird [in der Schleife] einfach das des vorherigen beibehalten, bis wieder eine Datei mit einem gültigen Datum kommt. Was kann ich denn tun? ich mein - der Dateimanager zeigt doch auch das richtige Datum (1.1.1970) an? Kann vielleicht einer eine Lösung für Delphi5 geben? (Weiß ja nciht, ob die neuren Delphi's das schon alles nicht mehr müssen ....)
Delphi-Quellcode:
procedure GetAllFiles2(mask: string);
var searchRec: TSearchRec; begin if FindFirst(mask, $23, search) = 0 then begin repeat nummer := nummer + 1; Form1.MeinARray[Nummer].DTime := FileDateToDateTime(searchRec.time); until FindNext(searchRec) <> 0; end;end;
Delphi-Quellcode:
und wo ich schon einmal dabei bin ... ich möchte das Dateidatum auch möglichst präzise als NICHT-Rational speichern (am besten als was ganzzahliges)
// Unterverzeichnisse scannen
if FindFirst(directory + '*.*', faDirectory, search) = 0 then begin repeat if ((search.Attr and faDirectory) = faDirectory) and (search.Name[1] <> '.') then GetAllFiles(directory + search.Name + '\' + ExtractFileName(mask)); until FindNext(search) <> 0; FindClose(search); end; also hab ich das mal mit z.B: 100.000 mal genommen und wollte dann alle Reste abschneiden. FullTIME := trunc(100000 * FileDateToDateTime(search.time)); Dummerweise wird FullTime dann aber negativ. Kennt jemand noch ne andere Möglichkeit das Dateidatum irgendwie als Zahl und später auch als String exportier und zurück importierbar zu speichern? Danke Euch. Wäre wirklich nett. |
AW: [D5] Dateidatum wird falsch gelesen
Hä? Wie liest du es denn aus? Welches Betriebssystem? Welches Dateisystem? Hast du auch die benötigten Rechte?
|
AW: [D5] Dateidatum wird falsch gelesen
Liste der Anhänge anzeigen (Anzahl: 2)
Zitat:
...hab den Code oben noch etwas um ne Aufrufprozedur ergänzt. Windows 7 64 Bit standard (NTFS) Rechte: Ja, eigenes Unterverzeichnis im Programmverzeichnis auf ner anderen Partition. Haben alle Programme Schreibrechte. Ich vermute allerdings eher, daß Delphi intern damit nicht klarkommt.(das alte aber geliebte Delphi 5) Also wenn ich das alle gescanneten Dateidaten mit Datum (formatiert, dahinter als Integer) ausgeben lasse, sieht man, daß ab Datei 05 [eigentlich 1.1.1970] das Datum von 04 übernommen wird und bei 05 Vorschlag - nochmal .jpg und - sehe ich gerade - sogar bis 06...GIF übernommen und selbst beim 06 nicht durch neue ersetzt wird.
Delphi-Quellcode:
kommt folgendes
0*Dateiname .... gelesenes Datum|Uhrzeit ..Filedate*10000 .... Dateigröße
01 Datei1.txt 04.12.2013 21:15:08 416128855 80171 02 Info.doc 07.04.2015 00:01:08 421010007 63091 03 Rechnung. xls 12.01.2015 21:09:38 420168816 487258 04 Alternativ.txt 12.09.2014 08:22:10 418943487 3735 05 Vorschlag.jpg 12.09.2014 08:22:10 418943487 24149 05 Vorschlag - Kopie.jpg 12.09.2014 08:22:10 418943487 24149 05 Vorschlag - nochmal .jpg 12.09.2014 08:22:10 418943487 24149 06 test.GIF 12.09.2014 08:22:10 418943487 5863 07 Briefumschlag.png 09.01.2015 23:13:30 420139677 242816 spi-curious-htr0061.jpg 08.12.2010 00:52:56 405200367 24039 alle 05 sind Kopien derselben - und haben alle das selbe LastChange Dateidatum 1.1.1970. Die 06.GIF hat 12.9.2014 ich hab fast allen Dateinamen eine 0Zahl vorangestellt, damit man sie (im Debugger) besser unterscheiden kann |
AW: [D5] Dateidatum wird falsch gelesen
Zitat:
Delphi-Quellcode:
Ergebnis wird sein: 01.01.1900 minus eine Sekunde. Datum 0 ist also dieses Datum.
var
DateTime: TDateTime; begin DateTime := 0; ShowMessage(DateTimeToStr(DateTime)); Was willst du also mit mal 100000 erreichen. Bedenke, Zeit 0 * 100000 ergibt 31.12.1899, ein Tag später mal 100000 ergibt das Datum 14.10.2173. Heute sind seit der Zeit 0 42111 Tage vergangen. Jede ganze Zahl steht für einen Tag. Also Now + 1 ergibt als Datum morgen. Nachkommastellen sind Uhrzeit. Wenn ich also Heute (42111) mal 10000 nehme, ergibt das 4211100000 Tage. Mal grob berechnet ergibt das 1900 + (4'211'100'000 / 356,25) etwa 11 Millionen Jahre in der Zukunft. |
AW: [D5] Dateidatum wird falsch gelesen
Zitat:
|
AW: [D5] Dateidatum wird falsch gelesen
ja, kann sein, daß die das bei den höheren Versionen schon geändert / präzisiert haben.
hier hab ich noch [nach FileDateToDateTime();] 41612,8855092593 für 04.12.2013 21:15:08 |
AW: [D5] Dateidatum wird falsch gelesen
Zitat:
Was aber Bjoerk meinte war nicht das Ergebnis der FileDateToDateTime Funktion, sondern von Search.Time. Das ist Integer. Dieser Integerwert wird mit der FileDateToDateTime in das Delphi Format konvertiert. Und das ist ein Double Wert. Die Vorkommastellen präsentieren das Datum, die Nachkommastellen die Zeit. Die Formel ist einfach: 1 / 24 / 60 / 60 / 1000. 1 ist der Tag. Du kannst dir also aussuchen was die 1 bedeutet, entweder 1 Tag oder 24 Stunden. Ist das Gleiche. Also 1 Tag / 24 Stunden/ 60 Minuten / 60 Sekunden / 1000 Millisekunden. Wobei bei dem Millisekunden Delphi schon ungenau ist. Was die Stunden, Minuten und Sekunden angeht, da stimmt alles. //Edit: Der maximale positive Wert von Integer ist 2147483647. Bei Longword ist es 4294967295. Aber bleiben wir bei Integer. MaxInt ist bei Integer also 2147483647, bzw. 2'147'483'647. Das sind 10 Zeichen. Now, bzw. Date, also der heutige Tag hat den Wert 42111, bzw. 42'111. Multiplizieren wir also den heutigen Tag mit 100000, bzw. 100'000, ist das Ergebnis 4211100000, bzw. 4'211'100'000. Der Wert ist also höher als der von Integer. Bei Logword hättest du da noch etwas Platz, aber nur für 838 Tage. Du solltest dich also mit deinem Programm beeilen, vorausgesetzt du nutzt Longword. Warum ist dein Wert aber negativ? Weil Integer den Bereich -2147483648..2147483647 hat. Das letzte Bit ist für das Vorzeichen. Wird es überschrieben, wird der Integer negativ. Die Idee mit der Multiplikation ist nicht optimal. Ich könnte dir nun vorschlagen es auf eine andere Art zu speichern, das wird aber auch knapp. Der Grund könnte daran liegen, dass das Delphi Datum am 01.01.1900 anfängt, das Datum von Dateien (soweit ich es weiß) am 01.01.1970. Das sind 25567,5 Tage unterschied. Das spart paar Bit. Aber nur falls du es dennoch so machen willst, Delphi kennt inzwischen Int64. Das könnte mit deinem Wert umgehen.
Delphi-Quellcode:
Nur weiß ich nicht ob D5 schon Int64 hat.
var
i64: Int64; DateTime: TDateTime; begin i64 := Trunc(Now * 100000); ShowMessage('Int64 = ' + IntToStr(i64)); DateTime := i64 / 100000; ShowMessage('Daum und Zeit nach der Umrechnung = ' + DateTimeToStr(DateTime)); end; |
AW: [D5] Dateidatum wird falsch gelesen
Zitat:
Ich würde mir SearchRec sparen und stattdessen mit FindFirstFile und dem von dieser Funktion gefüllten TWin32FindData arbeiten. Der Zeitstempel ist dort zwar gesplittet in Hi- und Low-Wert, aber da es genügend Beispiele im Netz zu FindFirstFile gibt, sollte das kein Problem sein. MfG Dalai |
AW: [D5] Dateidatum wird falsch gelesen
Zitat:
Danach kannst Du Dir mit DateTimeToStr(FileDateToDateTime(GespeicherterInte ger)) das Datum anzeigen lassen. |
AW: [D5] Dateidatum wird falsch gelesen
äh, mhh, jetzt ich bin langsam verwirrt :D
(naja, bin auch noch Programmieranfänger) also ich möchte alle Dateien in einem Verzeichnis scannen und das korrekte Dateidatum ermitteln. Naja OK, die weitere Speicherung ist zweitrangig - und wie sich ja ergeben hat, als integer - auch weniger leicht. a) Aber was ich nicht verstehe ist, warum Dateien mit dem Datum vor 1.1.1980 (gerade festgestellt ... Dateidatum VOR 1980 macht schon Probleme) von Delphi nicht mit searchrec.time ermittelt werden können? stattdessen wird der time-Wert der vorherigen Datei unverändert gelassen (und an den Array weitergereicht, wie man in den Screenshots im Anfangspost lesen kann). b) Auch das mit dem Findfirst versteh ich nicht. - ich dachte immer, der Befehl sucht nur das erste Vorkommen einer Datei (also z.B. Dateien mit 'rz****', oder '*.tmp') oder ähnliches. Aber dennoch schon mal allen Danke für die bisherigen Antworten. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 23:37 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz