OSDev.org

I have a FAT formatted disk image which is set as one of the hard drives in bochs. It is mounted using the "mount -o loop" command so that I can put user mode applications on it and test them. I use this script to compile the program and transfer it to the mounted image:
The problem is that it takes some time before the file gets copied to the disk image. The first couple times I run bochs the old version of the file is still on the image. Once I run bochs two or three times, it starts using the version of the file which was just copied over. Anyone know why it does this?

No. I'm using Linux.

are you mounting and then unmounting between bochs sessions?

Hi,

justin wrote:The problem is that it takes some time before the file gets copied to the disk image. The first couple times I run bochs the old version of the file is still on the image. Once I run bochs two or three times, it starts using the version of the file which was just copied over. Anyone know why it does this?

Either:

• The file system and loopback device fail to sync their cache/s to the disk image when it is unmounted (such that the disk image is up to date when "unmount" completes); or
• You failed to unmount the disk image before starting bochs, and there's a problem with the loopback device's file locking (e.g. the loopback device should lock the disk image, and Bochs should give you some sort of "failed to open disk image - file is locked by another process" error).

I'd suspect the latter.


Cheers,

Brendan

Brendan wrote: You failed to unmount the disk image before starting bochs, and there's a problem with the loopback device's file locking (e.g. the loopback device should lock the disk image, and Bochs should give you some sort of "failed to open disk image - file is locked by another process" error).

Problem solved. Thank you.

justin wrote:No. I'm using Linux.

And compiling to EXE? Welp.

Nessphoro wrote:

justin wrote:No. I'm using Linux.

And compiling to EXE? Welp.

.exe is a valid Linux executable extension.

IMHO I think it is weird that a linux user would be compiling to exe.

Aren't the compiled programs for the OP's OS, not Linux (even though he is developing on Linux)? If he chooses to use the .exe extension for executables in his OS, why not? It's useful on a FAT fs where names are restricted.

iansjack wrote:Aren't the compiled programs for the OP's OS, not Linux (even though he is developing on Linux)? If he chooses to use the .exe extension for executables in his OS, why not? It's useful on a FAT fs where names are restricted.

Yes. This is correct. The three letters at the end do not matter.

Well I don't see why one can't use an extension of say .elf. But that is op's choice and I don't really care.

TO OP: When I do on linux with qemu and loopback device, issue sync command flush the data to the image file and qemu can read the update image.
if your OS can write to the image it may however mess up the loopback if you do not disconnect it.

bluemoon wrote: TO OP: When I do on linux with qemu and loopback device, issue sync command flush the data to the image file and qemu can read the update image.
if your OS can write to the image it may however mess up the loopback if you do not disconnect it.

Thanks. I fixed the problem by enclosing the "cp" statement with "mount" and "umount" statements. I wasn't aware that you had to unmount the thing.

Nessphoro wrote: Well I don't see why one can't use an extension of say .elf. But that is op's choice and I don't really care.

You seem upset at my choice of extension. What is so much better about .elf?