Comment 10 for bug 898373

Note, assuming our theory on the circumstances of the race is correct above (that it is 'read' or mount of that device), I was unable to reproduce with a loop device, which I thought would have caused a similar issue:

1. truncate --size 100m /tmp/my.img
2. mkfs -F -t ext3 /tmp/my.img
3. LODEV=$(sudo losetup --show --find /tmp/my.img)
4. sudo python -c 'import time, sys; print sys.argv[1]; fp=open(sys.argv[1]); time.sleep(30); fp.close();' /dev/loop1 &
   # inside the 30 seconds that that will have an open RO file handle, do step 5
5. sudo fsck.ext3 -f /dev/loop1 # '-f' forces fsck even if not marked dirty
   or
    sudo fsck.ext3 /dev/loop1

Other things I've found:
 * using 'open(sys.argv[1],"rw")' does not change anything, fsck will still continue.
 * changing step 4 to 'mount -o ro /dev/loop1 /mnt' *will* cause fsck.ext3 to complain that the filesystem is mounted and print a similar error message.

So, I'm suspecting that it is indeed the OVF code's mount -o,ro that is causing this problem.

I'm not sure how to resolve it, other than limiting the mounts checked to FS of iso9660 only.