Re: [hatari-devel] Timestamp problem with GEMDOS drive

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

I added the --gemdos-time option to Hatari repo:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/55dc2366fed0
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/a2beeb7d7a4a

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
file timestamps.

(This of course assumes that rest of the files have reasonable timestamps when you're using something that relies on timestamps
to do things.)


	- Eero

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
gemdos.c::GemDOS_SetFileInformation().

Yes, removing that call fixes the problem.

If that works fine, propose a commandline option
for Hatari GEMDOS HD emulation.  Maybe:
	--gemdos-hosttime <bool>
or:
	--gemdos-time <host/atari>
?

I'm fine with any option, as long as it results in a proper GEMDOS HD
emulation time handling ;-).

Take care

Uwe

	- Eero

Best regards

Uwe

----- Uwe Seimet wrote:
Hi,

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.

Take care

Uwe


AFAIK
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.













Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/