|Re: [hatari-devel] Timestamp problem with GEMDOS drive|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
I added the --gemdos-time option to Hatari repo:
Note that while same Hatari instance is running, it's better
to do modifications only on host, or on Atari side. Then you
know which side's clock you should tell Hatari to use for
(This of course assumes that rest of the files have reasonable
timestamps when you're using something that relies on timestamps
to do things.)
On 02/19/2017 10:25 PM, Uwe Seimet wrote:
On 02/18/2017 10:06 PM, Uwe Seimet wrote:
I see, but this means that in particular make-like processes, which rely
on timestamps, do not work anymore. Pure C, for instance, now constantly
recompiles files without any need. This very inconvenient. Can this
somehow be fixed?
Are you using MegaST/e which takes time from host?
No, I'm using the TT emulation.
You could try ifdeffing out utime() call from
Yes, removing that call fixes the problem.
If that works fine, propose a commandline option
for Hatari GEMDOS HD emulation. Maybe:
I'm fine with any option, as long as it results in a proper GEMDOS HD
emulation time handling ;-).
----- Uwe Seimet wrote:
With the current development version I observe wrong timestamps when
compiling with Pure C. A C source file A.C has the timestamp 10:21.
After compiling it to A.O the resulting object file has the timestamp
10:20, i.e. it is not newer but older than the source file.
This is reproducable. The desktop shows that .O files are a minute older
than the .C files they were compiled from.
Hatari changed how it deals with the time of day.
Hatari grabs the current time when it is started, then
increments the time in "emulator time". This is causing
a conflict with the "actual time" as regards time stamps.