Re: [hatari-devel] Using device files as drive images?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 13 lokakuu 2014, Uwe Seimet wrote:
> A potential issue with device file images (at least under Unix) is that
> depending on the system setup (e.g. udev settings) partitions on memory
> cards etc. are mounted automatically. When Hatari is started and uses a
> device file with partitions that are already mounted data can be
> destroyed because several programs can independently write to the same
> device.

Don't use automount for things which you access also directly.
Or at least make sure to unmount them before that.


> In my case as soon as I insert a memory card with 3 Atari-compatible
> partitions these are mounted to /media/sdc[1-3]. When I now start Hatari
> and write data to these partitions these data are only visible in
> Hatari, but not in the /media/sdc[1-3] directories. Most likely when I
> now write something to /media/sdc[1-3] (e.g cp command on shell level)
> it will corrupt the data I've just written with Hatari before.
> It would probably be a good idea for Hatari to lock device files as long
> as they are in use.

I took a quick look at the available APIs.  flock() and lockf()
provide advisory locking and therefore aren't useful for this.

fcntl() supports both advisory and mandatory locking, but
mandatory locking has several issues:
- File system on which the file is, needs to be mounted
  with mandatory locking support
- File itself needs to be set to have mandatory locking,
  by disabling group execute permission on the file and
  enabling the set-group-ID permission bit
- the implementation of mandatory locking in all known versions
  of Linux is subject to race conditions which render it unreliable:
  a write() or mmap() call that overlaps with a lock may modify
  data after the mandatory lock is acquired

As it seems that file systems aren't normally mounted with
support for mandatory locking, there's not much point in
trying to lock things.


> And not to use device files with partitions that are mounted.

How do you propose detecting that, by parsing /proc/mounts?

(No idea where that info could be found on Windows, OSX
and BSD systems.)


> I'm not sure if all these scenarios can be covered by the
> locking APIs, though.
>
> With file images there is the same problem, but in practice
> auto-mounting file images is much less common than auto-mounting
> removable media.

Are you suggesting using advisory locking to prevent
multiple Hatari processes accidentally using the same
image files?


	 - Eero