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

[David Savinkoff <dsavnkff@xxxxxxxxx>]

Hi,

Maybe the time should have an option to be read on demand
from the host... as it was before. Then the user can choose to
set the clock either: Once at start-up 'or' On demand.

Note that a real Atari ST gets its time from a remote computer
(the keyboard). The Hatari host's time can be redirected
similarly as the host keyboard currently is.

One other thing: When a user sets the date and time on an
Atari ST. Does the date and time survive pressing the reset
button?


----- Uwe Seimet wrote:
> Hi,
> 
> Thank you for addressing this, but I'm afraid it does not work, at least
> not as I expected it to work. I may be missing something.
> I run hatari with "--gemdos-time host" and edit a C source file. When
> compiling my project the Pure C compiler detects that the file has changed
> and recompiles. Next time I trigger the compiler it compiles the same
> file again, even though there was no change and the resulting object
> file is newer than the source file. I trigger the compiler again and it
> recompiles the unmodified file and so on. It takes about a minute until
> the compiler realizes that there is nothing to compile.
> 
> Best regards
> 
> Uwe
> 
> > 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.
> > >>>>
> > >>>>