[hatari-users] Note on hard disk images and GEMDOS drives

Eero Tamminen eerot at users.berlios.de
Sun Nov 15 12:10:01 CET 2009


Hi,

On Sunday 15 November 2009, Uwe Seimet wrote:
> This is because the archive was created with STZIP on a FAT filesystem
> with no permission support.
>
> I have updated the demo archive by re-packaging it under Linux with
> the correct permissions.

Thanks!


> > -> There seems to be a bug in hddrutil.app that it doesn't warn if
> >     the hddriver file is read only and modifying it fails.  You may
> > want to fix that (along  with fixing the demo zip file contents file
> > permissions).
>
> I don't think there is anything wrong with HDDRUTIL. HDDRUTIL preserves
> the permissions of the driver file that is configured. This works under
> TOS, but with hatari the Fattrib() call does not seem to provide the
> correct file permissions

I looked at the Hatari code.  It should give the right permissions when
requesting them with Fattrib().  However, it doesn't:
- Support setting files as writable, only setting them as read-only (444)
  i.e. files need to set as writable outside Hatari
- give an error if file was read-only and it was requested to be set as
  writable

I'll fix latter to report both to user and to calling program.

However, with Hatari GEMDOS emulation it's possible to have just *specific*
files read-only so that the emulated programs cannot write them.  What would
be the correct error to return for those when program tries to set them as
writable?  File access denied (GEMDOS_EACCDN) or device being write
protected (GEMDOS_EWRPRO)?

(I'm trying to avoid confusing the Atari programs too much...)


> and when writing to the write-protected driver file hatari does not seem
> to return a GEMDOS error code.

This should work.  I think the issue is with Fattrib.


> I think there is also something wrong with the way hatari handles file
> timestamps. My Pure C compiler always compiles any file in a project,
> not just the modified files as it does with real Atari hardware. And
> when copying files under hatari with KOBOLD the copies do not have the
> timestamps of the original files but have the current date as their
> timestamp. This is also something where the behavior of hatari differs
> from a real Atari. Maybe the GEMDOS drive code of hatari can be improved
> with this respect.

In current GEMDOS emulation setting of file timestamp is explicitly
disabled.    I assume this is to avoid lots of files with "broken" 
timestamps from programs that cannot handle timestamps from
this millenium.

Thomas, any comments on this?


> > But it would be nicer if it would show up like that in the hddrutil.app
> > too. (And it would say something like "This cannot be changed in the
> > demo".)
>
> Where do you think this should show up? The driver you are configuring
> can reside on any drive, i.e. also on A:, B: or a drive not managed at
> all by HDDRIVER. HDDRUTIL can only report general problems when writing
> or modifying a file, but it cannot be specific and say that modifying
> was impossible because the file was located on a drive that was write
> protected because a demo version of HDDRIVER was used.

I meant that demo HDDRUTIL could show all drives except for A:, B: and C: as
being write protected in the "Write protection" dialog.  Probably not worth
the effort though...


	- Eero



More information about the hatari-users mailing list