[CLOSED] Get datetime of creation and of modification, for a file, under Linux lazarus / 32-Linux ---------------------------------------------------------------------- devEric69 · 2019-12-31 12:42 Hello, I would like to port this feature to Linux (it works on Windows): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i TenumFileDateProperty = (eCreation, eAccess, eModification);  {$If defined (Window)}uses ...;{$If defined(UNIX)}uses BaseUnix;{$EndIf}  function TFileUtils.FileGetDatePropertyDateTime(const sPathFile: string; iDateProperty: TenumFileDateProperty): TDateTime;{^explanation: returns a TDateTime of a property of the file passed as a parameter.- param. sPathFile: the full path to the file; e.g. /home/.../testFile.txt- iDateProperty parameter: the type of time- stamped property you want to know about^^}var{$If defined(Windows)}  SR: TSearchRec;  LocalFTime,  WichProperty: TFileTime;  STime: TSystemTime;{$ElseIf defined (UNIX)}  fAge: Longint;  aDateTime: TDateTime;  recInfo: stat;  hFile: LongInt;  SR: TSearchRec;{$EndIf} begin    case iDateProperty of{$If defined(Windows)}        try                (*Windows code*)              eCreation: WichProperty:= SR.FindData.ftCreationTime;              eAccess: WichProperty:= SR.FindData.ftLastAccessTime;              eModification: WichProperty:= SR.FindData.ftLastWriteTime;              if FindFirst(sPathFile, faAnyFile, SR) = 0 then begin                      FileTimeToLocalFileTime(WichProperty, LocalFTime);                      FileTimeToSystemTime(LocalFTime, STime);                      result:= SystemTimeToDateTime(STime);                end              result:= -1;                Raise EFilesUtils.Create('');      finally                System.SysUtils.FindClose(SR);        end;{$ElseIf defined (UNIX)}                (*Linux code*)              eCreation: begin                        (* //test 1:                      if FpStat(sPathFile, recInfo)<>0 then begin                              result:= -1;                                Raise EFilesUtils.Create('');                        end                      else begin                                aDateTime:= FileDateToDateTime(recInfo.ctime);                                result:= aDateTime;     // last *c*reation time                      *)                        (* //test 2:                        fAge:= FileAge(sPathFile);                        if (fAge<>-1) then begin                              aDateTime:= FileDateToDateTime(fAge);                      result:= aDateTime;                        end;                      *)                        (* //test 3:                      hFile:= FileOpen(sPathFile, fmOpenRead);                      fAge:= FileGetDate(hFile);                        aDateTime:= FileDateToDateTime(fAge);                        result:= aDateTime;                      FileClose(hFile);                        *)                      //test 4:                        if FpStat(sPathFile, recInfo)<>0 then begin                                result:= -1;                              Raise EFilesUtils.Create('');                      end                        else begin                              aDateTime:= FileDateToDateTime(recInfo.ctime);                              result:= aDateTime;     // last *c*reation time                      end;                end;                 eAccess: begin                        if FpStat(sPathFile, recInfo)<>0 then begin                              result:= -1;                                Raise EFilesUtils.Create('');                        end                      else begin                                aDateTime:= FileDateToDateTime(recInfo.atime);                                result:= aDateTime;     // last *a*cces time                        end;                end;{$EndIf}    end;end;  I'm testing the function with this call: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure TfrmMain.Button1Click(Sender: TObject);begin  ShowMessage('Creation date: '+DateTimeToStr(        {TFileUtils.}FileGetCreationDateTime('/home/.../.../fileTested.pas')            ));end; In fact, I only get the true creation date with test 2: "fAge:= FileAge(...". But, as soon as I've modified the file to see if the creation date remained the same, then 'test 2' returned me the modification date. Does anyone know how to retrieve the creation and modification date under Linux? The "dev"ice partition of my Linux filesystem is formatted in ext4 (command in the terminal: df -Th | grep "^dev"). ps: I use the Cinnamon desktop (in addition to the Nautilus desktop). When I modify a file, the Cinnamon desktop always shows me the same creation date (Cf. image). Regards. ---------------------------------------------------------------------- lucamar · 2019-12-31 12:54 You can use fpStat() (in unit BaseUnix). In the resulting record Stat the parts you're looking for are: Last access time: st_atimeLast modification time: st_mtimeCreation time: st_ctime ETA: Remember that those are Unix timestamps so you need to use TimeStampToDateTime to convert them. Or, yeah, FileDateToDateTime, as you're doing ---------------------------------------------------------------------- MarkMLl · 2019-12-31 13:45 Also make sure that the appropriate variants of the  ls  command show you the dates you expect, and be aware of  lsattr  etc. even if not directly relevant. MarkMLl ---------------------------------------------------------------------- devEric69 · 2019-12-31 13:49 I've tested with this code (using the other variant part of the record; those with st_*), and a new created file (with same modification datetime, too): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i FpStat(sPathFile, recInfo)<>0 then beginaDateTime:= FileDateToDateTime(recInfo.st_ctime);result:= aDateTime;     // last *c*reation time So, indeed, it works... but only the first time (on my computer, at least): I get the correct creation date. But, if I modify the same file, then this same code gives me the modification date (with st_ctime, st_mtime, or st_atime)??! Does anyone else observe the same behaviour under *nix? QuoteAlso make sure that the appropriate variants of the  ls  command show you the dates you expect, and be aware of  lsattr  etc. even if not directly relevant. Okay, I'll check with terminal commands. ---------------------------------------------------------------------- winni · 2019-12-31 14:21 Hi! You are looking for the wrong result of FpStat. 0 means: everything ok, <> 0 means error. Runs without a problem: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i if FpStat('/tmp/st-test.txt', recInfo)=0 then begin   s := DateTimeToStr(FileDateToDateTime(recInfo.st_ctime)) + LineEnding +      DateTimeToStr(FileDateToDateTime(recInfo.st_mtime)) +LineEnding+      DateTimeToStr(FileDateToDateTime(recInfo.st_atime)) ;   ShowMessage (s);   end else showMessage ('Nada');       Winni ---------------------------------------------------------------------- MarkMLl · 2019-12-31 14:26 Some of the semantics might be filesystem-specific, hence my suggestion that you familiarise yourself with lsattr etc. There's definitely at least one attribute in there that changed how some of the timestamps work, and I think that can also be changed on a per- filesystem basis although the detail escapes me. My recollection is that the creation time (ctime) is basically the inode creation timestamp, with other timestamps stored (and updated) inside the inode. Check before you trust that statement :-) You might find it worth zeroing recInfo before the FpStat() so that you know that it's being updated. > You are looking for the wrong result of FpStat. > 0 means: everything ok, <> 0 means error. That as well :-) MarkMLl ---------------------------------------------------------------------- lucamar · 2019-12-31 14:43 Quote from: devEric69 on December 31, 2019, 02:49:45 pmDoes anyone else observe the same behaviour under *nix? No, sorry. This q&d test: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Project1; {$mode objfpc}{$H+} {$IFNDEF UNIX}{$Error Unix only!!!}{$ENDIF} uses  SysUtils, BaseUnix; var  st: Stat;  err: cint; begin  if (ParamCount > 0) and FileExists(ParamStr(1)) then begin    err := FpStat(ParamStr(1), st);    if err <> 0 then      WriteLn('Stat error: ', err)    else begin;      writeln('Creation    : ', DateTimeToStr(FileDateToDateTime(st.st_ctime)));      writeln('Modification: ', DateTimeToStr(FileDateToDateTime(st.st_mtime)));      writeln('Last Access : ', DateTimeToStr(FileDateToDateTime(st.st_atime)));    end;  end else    WriteLn('Need some file to test its dates!');end. gives this output with some (arbitrarily selected) file: Code: [Select]Creation    : 03-07-2019 00:54:09 Modification: 12-12-2017 13:05:56 Last Access : 05-12-2019 20:57:29 which AFAICT is quite correct: the file is an MP3 I copied over from an older disk in Summer and I played it last early this month. ---------------------------------------------------------------------- devEric69 · 2019-12-31 16:05 Quote0 means: everything ok, <> 0 means error.Sorry about that reverse test . Quotewhich AFAICT is quite correct: the file is an MP3 I copied over from an older disk in Summer and I played it last early this month.Good music, then . Thanks for the test. In a paranoid reflex, I copied and pasted *your* code (I just replaced the Writeln with a ShowMessage, and tested it without the error test (assuming it works), and with the error test (paranoid reflex, always): - I created a new empty file ("$ touch") at 16:10. I ran the code: the creation time is Ok, like the 2 others. They are identical to 1 second accuracy near. - I've waited 7 minutes, I've added a line "blabla" in this same text file, and I've started the code again: unfortunately for me, the 3 dates are all identical: 16:17 (modification date). But the Cinnamon desktop - fortunately, it's there - indicates that the file was really created at 16:10, and was then modified at 16:17. ==> I'll install the cross-compiler for Linux 32bits, and re-test on a netbook LUbuntu 32bits (ext4, too). ps: aftermath of my failed test: I did a search on the internet. Several sites say that the creation date (or birthday date) since ext4 would be stored in a new field named "crtime: Shows file creation time" field (the article: https://www.tecmint.com/debugfs-command- show-file-creation-time-in-linux/ ). @lucamar: is your test on ext3 or ext4, please (command in the terminal: df -Th)? ---------------------------------------------------------------------- MarkMLl · 2019-12-31 16:35 Remember I said something about checking using the  ls  command? These command issued roughly a minute apart: Code: [Select]$ date && touch veeblefetzer Tue 31 Dec 16:30:03 GMT 2019 $ ls -l ve* && ls -l --time=ctime ve* && ls -l --time=atime ve* -rw-r--r-- 1 markMLl markMLl 0 Dec 31 16:30 veeblefetzer -rw-r--r-- 1 markMLl markMLl 0 Dec 31 16:30 veeblefetzer -rw-r--r-- 1 markMLl markMLl 0 Dec 31 16:30 veeblefetzer $ cat ve* $ ls -l ve* && ls -l --time=ctime ve* && ls -l --time=atime ve* -rw-r--r-- 1 markMLl markMLl 0 Dec 31 16:30 veeblefetzer -rw-r--r-- 1 markMLl markMLl 0 Dec 31 16:30 veeblefetzer -rw-r--r-- 1 markMLl markMLl 0 Dec 31 16:31 veeblefetzer $ echo x >> ve* 0 1>markMLl@desktop:~$ ls -l ve* && ls -l --time=ctime ve* && ls -l --time=atime ve* -rw-r--r-- 1 markMLl markMLl 2 Dec 31 16:32 veeblefetzer -rw-r--r-- 1 markMLl markMLl 2 Dec 31 16:32 veeblefetzer -rw-r--r-- 1 markMLl markMLl 2 Dec 31 16:31 veeblefetzer So mtime and ctime on ext4 seem to track each other, but atime can be modified (in the inode) without anything else changing. Oy vey"! This is hardly the first time I've done tech support on New Year's Eve :-) MarkMLl ---------------------------------------------------------------------- lucamar · 2019-12-31 16:56 Quote from: devEric69 on December 31, 2019, 05:05:31 pm- I've waited 7 minutes, I've added a line "blabla" in this same text file, and I've started the code again: unfortunately for me, the 3 dates are all identical: 16:17 (modification date). That quite depends on how you edit the file. If the program renames the old file, creates a new one and saves the old/new data to it then all three dates are (quite logically) the same. QuoteBut the Cinnamon desktop - fortunately, it's there - indicates that the file was really created at 16:10, and was then modified at 16:17. Then something is wrong with fpstat, though I can't see what: it just calls the system's stat, IIRC Quoteis your test on ext3 or ext4, please Ext3; I never use ext4 on (semi-)critical boxes. Now that I think about it, I never use it if I can avoid it: too easy to break. I see your point, though: you were talking about ext4 partitions and my tests were in ext3 (and 32 bits, moreover) Sorry about that ---------------------------------------------------------------------- winni · 2019-12-31 17:10 Hi! Before any checking of file dates you have to do a Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i sync to force the buffers to be written onto disk. after that you can check the dates! Winni ---------------------------------------------------------------------- MarkMLl · 2019-12-31 17:21 Quote from: winni on December 31, 2019, 06:10:46 pmHi! Before any checking of file dates you have to do a Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i sync to force the buffers to be written onto disk. after that you can check the dates! Winni Well I certainly didn't. The buffered directory entries etc. in memory should be checked before disc, that's what "primary storage" is for. MarkMLl ---------------------------------------------------------------------- devEric69 · 2019-12-31 17:42 QuoteSo mtime and ctime on ext4 seem to track each other, but atime can be modified (in the inode) without anything else changing. ==> Bingo????! I'll only going to test - tomorrow - on another Ubuntu (same version 18.04 LTS, ext4, 64bits) and a 32bits Linux, but ext4 too. Amho, if someone would have a virtual box  with several different *nix, it would be interesting, to corroborate, or to invalidate, the ext4 versus ext3 hypothesis ("mtime and ctime on ext4 seem to track each other")... QuoteI see your point, though: you were talking about ext4 partitions and my tests were in ext3 (and 32 bits, moreover) Sorry about that. It's no problem: it was impossible to know, from where it came; on the contrary, your test on ext3 increases the probability of the hypothesis, that ext4 manages the creation date differently from ext3 (MarkMLl also observes it under ext4). I prefer to end the year with an "almost" certitude . QuoteBefore any checking of file dates you have to do a sync@winni: I'm sorry. But this idea doesn't seem to be working: - I've created an empty file at 18:16. - I've waited, and modified it at 18:32. - I've ran the cmd "sync", as user and as admin "sudo -i" (ie root) - I've asked for the dates: the 3 indicate 18:32 (the Cinnamon office, refreshed, continues to distinguish the creation at 18:16 and the modification at 18:32. I must quit this discussion's thread for today. Happy New Year to you, to the other administrators, and to the Lazarus support people    !!! ==> I'm ending this discussion for today. ---------------------------------------------------------------------- MarkMLl · 2019-12-31 17:55 > - I've waited, and modified it at 18:32. How, /exactly/ did you modify it? if you used any sort of text editor then you might actually be looking at a new file, check that the inode is the same (I think ls has an option for this- possibly -i). Oh, and what makes you think that Crinoline Office is giving you the right result? There could be more bugs in that that in your code that you're trying to debug... there really are very good reasons that my example used the  ls  and  echo  commands. I think I might have an ext3 system on Qemu, I'll try to take a look but it won't be immediate. MarkMLl ---------------------------------------------------------------------- MarkMLl · 2019-12-31 18:55 Here's a test script: Code: [Select]#!/bin/bash V=veeblefetzer rm $V date && touch $V ls -il $V ls -il --time=ctime $V ls -il --time=atime $V sleep 90 date && cat $V ls -il $V ls -il --time=ctime $V ls -il --time=atime $V sleep 90 date && echo x >> $V ls -il $V ls -il --time=ctime $V ls -il --time=atime $V rm $V Here's the result on ext4: Code: [Select]Tue 31 Dec 18:44:55 GMT 2019 3017024 -rw-r--r-- 1 markMLl markMLl 0 Dec 31 18:44 veeblefetzer 3017024 -rw-r--r-- 1 markMLl markMLl 0 Dec 31 18:44 veeblefetzer 3017024 -rw-r--r-- 1 markMLl markMLl 0 Dec 31 18:44 veeblefetzer Tue 31 Dec 18:46:25 GMT 2019 3017024 -rw-r--r-- 1 markMLl markMLl 0 Dec 31 18:44 veeblefetzer 3017024 -rw-r--r-- 1 markMLl markMLl 0 Dec 31 18:44 veeblefetzer 3017024 -rw-r--r-- 1 markMLl markMLl 0 Dec 31 18:46 veeblefetzer Tue 31 Dec 18:47:55 GMT 2019 3017024 -rw-r--r-- 1 markMLl markMLl 2 Dec 31 18:47 veeblefetzer 3017024 -rw-r--r-- 1 markMLl markMLl 2 Dec 31 18:47 veeblefetzer 3017024 -rw-r--r-- 1 markMLl markMLl 2 Dec 31 18:46 veeblefetzer Here's the result on ext3: Code: [Select]Tue Dec 31 18:45:02 GMT 2019 3797947 -rw-r--r--    1 markMLl  users           0 Dec 31 18:45 veeblefetzer 3797947 -rw-r--r--    1 markMLl  users           0 Dec 31 18:45 veeblefetzer 3797947 -rw-r--r--    1 markMLl  users           0 Dec 31 18:45 veeblefetzer Tue Dec 31 18:46:32 GMT 2019 3797947 -rw-r--r--    1 markMLl  users           0 Dec 31 18:45 veeblefetzer 3797947 -rw-r--r--    1 markMLl  users           0 Dec 31 18:45 veeblefetzer 3797947 -rw-r--r--    1 markMLl  users           0 Dec 31 18:46 veeblefetzer Tue Dec 31 18:48:02 GMT 2019 3797947 -rw-r--r--    1 markMLl  users           2 Dec 31 18:48 veeblefetzer 3797947 -rw-r--r--    1 markMLl  users           2 Dec 31 18:48 veeblefetzer 3797947 -rw-r--r--    1 markMLl  users           2 Dec 31 18:46 veeblefetzer Note how I'm writing to the file, and note that the inode number remains consistent. The bottom line appears to be that with those commands mtime == ctime. I suggest that it might be worth researching the output from the  stat  command. MarkMLl ---------------------------------------------------------------------- devEric69 · 2019-12-31 20:24 QuoteNote how I'm writing to the file, and note that the inode number remains consistent. That's clever (I'm not on my machine: I can't say the name of the graphic editor, I've used to edit my file). QuoteThe bottom line appears to be that with those commands mtime == ctime. I suggest that it might be worth researching the output from the  stat  command. From article to article about inode's information storage, I came across this: "The inability of "stat" to display the creation time is due to the limitation of the system call "stat", whose return structure didn't include a field for the creation time. Starting with Linux 4.11 (i.e. Ubuntu 17.10 and newer), the new "statx" system call is available, which includes a creation time in its return structure." source: "https://manpages.ubuntu.com/manpages/artful/en/man2/statx.2.html" (This page is part of release 4.13 of the Linux man-pages project; Cf. stx_btime field: it's the file's creation timestamp). I know that my kernel is 4.15.etc. There are many articles like "return enhanced file attributes from the Ext4 filesystem". At the beginning, it seems that some coders added this patch (source code) and compiled their kernel themselves. Then, the patch would have been merged into official kernels. But I would continue to "investigate" - definitely - only last year . ---------------------------------------------------------------------- winni · 2019-12-31 20:45 Hi ! Investigations in THIS year: stat on the bash: Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i stat --version  Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i stat (GNU coreutils) 8.31Copyright (C) 2019 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later .This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.  stat on ext3 Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i stat  /tmp/st-test.txt Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  File: /tmp/st-test.txt  Size: 7               Blocks: 8          IO Block: 4096   regular fileDevice: 802h/2050d      Inode: 6829413     Links: 1Access: (0777/-rwxrwxrwx)  Uid: ( 1000/   winni)   Gid: (  100/   users)Access: 2019-12-30 00:28:07.248312323 +0100Modify: 2019-12-30 00:27:52.035091768 +0100Change: 2019-12-31 15:16:06.232660219 +0100 Birth: 2019-12-30 00:27:52.035091768 +0100   Cheers! Winni ---------------------------------------------------------------------- MarkMLl · 2020-01-01 10:15 Quote from: devEric69 on December 31, 2019, 09:24:19 pmThat's clever (I'm not on my machine: I can't say the name of the graphic editor, I've used to edit my file). Don't do that. I used  echo >>  with good reason. I obviously can't speak for whatever editor you're using since not even you know what it is (insert slightly impatient smiley here), but there's a longstanding unix convention that when something edits a file the *original* is saved as a backup and a *copy* is given the name of the original. The objective is to ensure that a user who might only have read access can't screw around with the original: the next time he tries to save it might fail since he can't delete or rename the backup. Now obviously I don't know whether whatever editor you're using is doing this, but there's a fair chance that even if it's not actually saving a backup it's still paying lipservice to the convention. Hence the importance of looking at the inode number, since if the editor is actually saving a new file all of your other points about stat/statx are irrelevant. MarkMLl ---------------------------------------------------------------------- devEric69 · 2020-01-01 11:37 I took a test this morning. (and I've used only "touch", then "echo" too, then "Vi" to check the text added,and finally "statx"). The comments are annotated in the screenshots. ---------------------------------------------------------------------- devEric69 · 2020-01-01 11:48 From this page https://github.com/whotwagner/statx-fun, I've compiled a binary program named statx (Cf. statx.zip: it's a very small program that only calls the statx C function included in this program; this new C function statx is, if I understood correctly, now included in rather recent Linux kernels, like Ubuntu 17.04 17.10 and more): it returns correctly the creation date, whereas "stat" doesn't return any "birthady date" on my ext4 filesystem. It's pretty conclusive with what I've read "on the diagonal" on the Web, but for me alone, because it's just ...1 test, ...on my station. ---------------------------------------------------------------------- MarkMLl · 2020-01-01 12:32 I appear to have muddied the water earlier in the thread by referring to ctime as creation time, when it should have been change time. However my recollection is that one has to be careful with some of those times, since one of them (ctime?) refers to the inode (i.e. including anything which can be stored in extended attributes) rather than the file itself. MarkMLl ---------------------------------------------------------------------- lucamar · 2020-01-01 12:46 Looks as if a fpstatx function should be added in, say, BaseUnix for newer kernels, isn't it? Maybe you should add a bug report and a patch? It shouldn't be too difficult, just look at how fpStat is implemented and do something similar for fpStatx Quote from: MarkMLl on January 01, 2020, 01:32:32 pmI appear to have muddied the water earlier in the thread by referring to ctime as creation time, when it should have been change time. However my recollection is that one has to be careful with some of those times, since one of them (ctime?) refers to the inode (i.e. including anything which can be stored in extended attributes) rather than the file itself. I made the same mistake but re-reading "man 2 stat" it clearly says: Quote[...]     time_t    st_atime;   /* time of last access */     time_t    st_mtime;   /* time of last modification */     time_t    st_ctime;   /* time of last status change */ [...] The field st_ctime is changed by writing or by setting  inode  information  (i.e., owner, group, link count, mode, etc.). It just happens that for many (most?) data files the last inode "change" occurs when the file is created, so the confusion is understandable. ---------------------------------------------------------------------- MarkMLl · 2020-01-01 12:54 Quote from: lucamar on January 01, 2020, 01:46:04 pmI made the same mistake but re-reading "man 2 stat" it clearly says: As does the manpage for the  ls  command, which I'm pretty sure I suggested should be studied (there's no way that I can remember things like those --time parameters, and I tend to underuse the  stat  command). I'm currently looking at something which needs elevated capabilities, and since these are stored in the EAs (hence are lost if a file is copied or archived) the creation and modification time aren't the same. I suspect there might be more cases where they differ on a Mac. MarkMLl ---------------------------------------------------------------------- devEric69 · 2020-01-01 13:11 There is indeed a fuzzy with ctime, because I think it would have evolved, at the mement of the appearance of ext4. My understanding is that ctime was historically really the date of *c*reation for kernels that were installed on ext3 (@Winni sees it well, as a constant creation date). But, the kernels installed on ext4, have on the other hand the same function stat which always returns a result in ctime, but the result ctime seems to be the *c*hange time, now. And the date of creation isn't accessible any more. Birthday date seems to have disappear under ext4... ...Hence the creation, of a new structure for the new statx function specific to ext4, which adds a *cr*time field in order to find the creation date again. Then, some kernels would have recently merged the injection of this new statx function (Ubuntu, for example, has injected it in its kernels only since Ubuntu 17.10). edit: https://github.com/torvalds/linux/commit/a528d35e8bfcc521d7cb70a af03e1bd296c8493f (committed Jan 31, 2017): Quote" statx: Add a system call to make enhanced file info available Add a system call to make extended file information available, including file creation and some attribute flags where available through the underlying filesystem ... [snip] ... Functions like vfs_stat() are now inline wrappers around new functions vfs_statx() and vfs_statx_fd() to reduce stack usage. [snip] ... =============== NEW SYSTEM CALL =============== The new system call is:    int ret = statx(int dfd,          const char *filename,          unsigned int flags,          unsigned int mask,          struct statx *buffer);" ==> Unless someone has an objection, can I make an "upgrade request" in Mantis anomaly tracker, to ask to import this new feature into the Linux-oriented Lazarus source code? ---------------------------------------------------------------------- MarkMLl · 2020-01-01 14:26 Quote from: devEric69 on January 01, 2020, 02:11:21 pmThere is indeed a fuzzy with ctime, because I think it would have evolved, at the mement of the appearance of ext4. The ext3 example I gave yesterday was on a late v2 kernel, somewhere around 2.34 IIRC. Quote from: devEric69 on January 01, 2020, 02:11:21 pm==> Unless someone has an objection, can I make an "upgrade request" in Mantis anomaly tracker, to ask to import this new feature into the Linux- oriented Lazarus source code? This isn't a Linux issue, it's an FPC (or strictly RTL) one. I agree that it would be worth raising via Mantis. MarkMLl ---------------------------------------------------------------------- devEric69 · 2020-01-02 09:41 An upgrade request for Linux \ ext4 has been made ( https://bugs.freepascal.org/view.php?id=36501 ).