Re: [hatari-devel] fopen traces

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On keskiviikko 13 toukokuu 2015, Eero Tamminen wrote:
> Any additional comments on this?

Information I was thinking of adding on this to Hatari manual:
-------
"files" trace option can be used to track TOS file accesses;
what files programs try to open and what potential problems
there are with that (missing files, wrong access rights etc).
For larger programs one could also think of it as startup
progress indicator.

It's a subset of "gemdos" trace option output.  Full GEMDOS
trace is verbose and can interleave (mess) Hatari's
"--conout 2" (TOS console) output, so you could try "files"
option before resorting to full "gemdos" or "os_all" option.

(To find the interesting data from more verbose options, one
often needs to redirect them to a file and search that.)

Similarly to "gemdos" trace option, "files" option needs to
be given at Hatari startup, if you want to tract file accesses
also to floppies and and hard disk images, not just GEMDOS HD
emulated drive(s).  Errors are reported only by GEMDOS HD
emulation.
-------

Besides Fopen/Fclose, I think also Pexec & Pterm* would
be interesting, because you can see from Pterm whether
program terminated abnormally.  However, I'm not sure
what this kind of trace option should then be named...


	- Eero

> On tiistai 07 huhtikuu 2015, Eero Tamminen wrote:
> > On maanantai 06 huhtikuu 2015, Nicolas Pomarède wrote:
> > > Le 06/04/2015 21:30, Eero Tamminen a écrit :
> > > problem is that "files" looks to generic to me. Does it traces fopen,
> > > fseek, fclose, fsnext, fread, frwite, ... ? At the moment not, and
> > > that's what I would expect from an option that says it traces files :
> > > to trace all kind of files' operations, not just fopen.
> > 
> > I've thought that it could trace also fclose() as it already
> > traces fopen().
> > 
> > However, I'm not going to add e.g. Fwrite() there, it's one
> > of those functions which really messes the output (in a way
> > that's not fixable with grepping).  MiNTlib seems to do printf()
> > output with Fwrite() call *per letter* i.e. every letter output
> > by "--conout 2", gets additional GEMDOS trace output.
> > 
> > Besides, file system operations which can modify file system
> > content:
> > - mkdir
> > - rmdir
> > - fcreate
> > - fwrite
> > - fattrib
> > - delete
> > - rename
> > - fdatime (write)
> > 
> > already provide an error message if file system modification
> > fails under GEMDOS HD due to write protection enabled by user.
> > 
> > The other errors for which normal Hatari users could do
> > something (= related to host file system operation errors)
> > are currently printed only under full GEMDOS tracing.
> > They are be something that "files" trace could output too.
> > What do you think?