WIN32Ada - inconsistent results with time data of files

General
1

Hello all,
I am having some small challenges getting file time stamps

Platform: Windows10/11, 64 bit OS and processor.
Win32ada 25.0.0

In Windows files have 3 time properties, access time, creation time and modification time.

Short version: How can get the correct file times?

(much) longer version:
Using the WIN32Ada interface there are (at least) 2 ways of getting these times: Win32.crt.Stat.Stat, which returns a struct_stat record; and Win32.crt.Io.findfirst which returns a findata_t record. Both records have 3 time fields, of type Win32.crt.Types.time_t, representing the nr of second since EPOCH (01-jan-1970 00:00:00). In Win32 time_t is a 32-bit type, so for sure it will have a year 2038 problem if left unchanged.

And then there are Ada.Directories.Modification_Time which return Ada.Calendar.Time and GNAT.Os_Lib.File_Time_Stamp which returns GANT.OS_Lib.OS_Time

When I use these functions and compare them to the time stamps of a file in its property sheet the result do not agree
Time stamps according to property sheet:

  • created : 18-Sep-2026 18:02:36
  • modified: 12-Nov-2025 17:50:44
  • accessed: 16-Sep-2026 18:02:36

Time stamp according Ada.Directories.Modification_Time:

  • modified: 12-Nov-2025 17:50:44 ==> agrees with file property sheet

Time stamp according GNAT.OS_Lib.File_Time_Stamp:

  • time stamp: 12-Nov-2025 16:50:44 ==> agrees with file property sheet modification time, given the time zone

Time stamps according Win32.Crt.Stat.Stat:

  • created : 12-Nov-2025 17:50:44 ==> is the modified time in the property sheet
  • modified: 01-Jan-1970 00:00:00 ==> no match what so ever
  • accessed: 21-Sep-2026 16:54:41 ==> no match what so ever
    Online search for the relevant C documentation on stuct stat I can’t find any agreement on the order of elements

Time stamps according Win32.Crt.Io.findfirst:

  • created : 01-Jan-1970 09:05:58 ==> no match what so ever
  • modified: 01-Jan-1970 00:00:00 ==> no match what so ever
  • accessed: 18-Sep-2026 17:02:36 ==> matches created in file property sheet, given the time zone
    Furthermore, in the ‘name’ field (type Char260) the first 16 (or so) elements are bogus; and the reported file size is also incorrect. The results suggest a misalignment with the actual C implementation.

So, how come the Win32ada values are way off?
And how can I get the correct values for the file time stamps?

(Sorry for the amount of text)

2

Either use native Windows API or else the Ada Standard Library. If unsure check the standard library implementation source.

Do not use POSIX / UNIX / Borland layers, they are garbage both logically and semantically. On top of that MS never cared about them. I vaguely remember that some of the dozens functions starting a thread actually leak memory. Morale: see above.

P.S. Win32Ada is not really necessary. First of all it is far from being complete. Secondly, you can pretty easily call Win32 API directly using the stdcall convention and remembering that Windows’ W-calls are UTF-16, which normally would be UCS-2 = Wide_String.

3

Note that the ada standard library gives me only the modification time (Ada.Directories.Modification_Time). I want the accessed and creation times as well.

Using the native API seems doable.

That leaves the question on which struct layout to use. For the C stat struct there are numerous disagreeing definitions. Is the info in the MS Learn site correct? Especially the field order is complete different compared to what can be found on other websites (and in win32ada where the call is directly to the native API)

4

Because it is the greatest common denominator.

All depends on the file system at hand. NTFS, ext4, zfs have the creation time. As for the access time it is very unreliable, e.g. you can have none whatsoever, or turned off for performance reasons.

Do not use the CRT layer (as we all know, Windows was not written in C, Basic it was :grinning_face:). Use the native API:

This is what a Windows file system driver would report back on request.

5

Thanks. Give me 3 weeks to test it, Away for a belated holiday