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

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


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



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