I use

qemu win98bug.img -hdb fat:rw:test

I know from /usr/share/doc/qemu/qemu-doc.html that I shouldn't use
non-ASCII filenames, etc.

Apparently data loss occurs, if the *contents* of the file contain some
non-ASCII characters.

1. Ordinary txt file

- In windows, I create a txt file and edit it with notepad.

- If the text of that file just contains ASCII characters everything is
fine.

- If I add one German umlaut A, everything is fine, I can change and save
the text. On reboot of the guest all changes will be lost!

2. Office document

- In openoffice.org on the host's etch, I create a document with one word
"test" in it (only the 4 letters), save it as 'Microsoft Word 97/2000/XP'
and copy it to the test-directory.

- I open and close the file ok from within windows 98 / office 2000 (word)
as long as I don't change anything.

- I add *one* letter to the "test" text --> "testa" and save the document
from M$ office on the guest and shutdown / reboot the guest

- the file is corrupted: word will report "Document name or path invalid"
(my translation from German). Openoffice will freeze on trying to open the
document.

This also happens to more complex documents.

The same image file works fine with the same office document (and many
others), if I don't use the above command line, but just use

qemu win98bug.img

and install samba 'properly' on the host.

Since there is also #419515, this seems to be the *only* choice as far as
data transfer between guest and host is possible.

It was quite a learning experience to me to get it working, however,

*Thanks for the good work*

and for providing a means of not having to shutdown debian, just to be able
to edit the odd word document that won't render properly in Openoffice.org!

Johannes

NB: the folder in quesiton is on a standard ext3 partition, if this is
relevant. I experimented a little with using one on a fat32 partition, but
that didn't make a difference IIRC.

severity 419929 important
thanks

This only concerns one feature of qemu, and only concerns the data you
try to modify in the guest. It's data loss, but I won't call that
*serious* data loss.

I really doubt it is due do non-ASCII characters. It's probably due to
buffers not written to the disk when the guest is shutdown.

There has been a lot of code changes on that side in qemu 0.9.0, so I
really think the bug has been fixed. Care to retry with this version ?

Aurelien Jarno wrote:

I won't be picky about what kind of data loss is serious or not. In this
particular case, user data are get corrupted without any user
interaction except opening and modifying a document. If you wouldn't
call that 'serious data loss' at least you should call it 'data loss'.
That means severity 'grave' [1], not important.
[snip]

I would like to. The only problem is that I am quite happy at the moment
with my *stable* system(s) and updating would require to also update
libc6, essentially moving too much of the system to testing/unstable.

Are you planning on releasing a backport? It will require some time and
space for me to install and setup another system for verification of
this issue.

Thanks,

Johannes

[1] http://www.debian.org/Bugs/Developer#severities

The severity level of this bug has been set to [1]:

important:  a bug which has a major effect on the usability of a
   package, without rendering it completely unusable to everyone.

In fact this bug leads to data loss and severely limits the usability of
the program, because it limits data exchange between the host and the
virtual machine. 'Productive use' of any program running on a virtual
machine --apart from testing and 'playing games'-- requires reliable
means to exchange data between guest and host.

Due to the fact that this bug leads to data loss (serious or
non-serious) I kindly ask you to reconsider the severity level.
I suggest the more appropriate level would be [1]

grave: makes the package in question unusable or mostly so, or causes
  data loss, or introduces a security hole allowing access to the
  accounts of users who use the package.

Improper use of severity levels violates the 'We will not hide problems'
stanza of the social contract [2].

Johannes

[1] http://www.debian.org/Bugs/Developer#severities
[2] http://www.debian.org/social_contract

Hi,

This bug is affecting qemuctl package seriously, making it unusable in
actual state.

Please, reconsider the the severity of this bug to RC level.

Thanks.

Please forget last entry. I choose a wrong bug number. This must be
applied to #452235, not #419929.

This has nothing really to do with windows 98, but affects every guest.
The thing is -- writable vFat "disks" are not the most reliable things
out here, they tend to fail in one or another way due to the amount of
ugliest/hackiest amount of emulation added into the mix.  This thing is
impossible to do "right" because there's no "right", especially when
you consider that the files behind this "disk" can be modified on the
host while qemu is running, and there's no way to notify guest about
this changes, at all.  It might be even worse than two OSes at the
same time trying to modify the same FAT filesystem.

vfat is a last-resort quick-n-dirty fix for a problem when you have a
guest which doesn't have any other ways to communicate except of a
fat image (read: a floppy).  In all other cases just don't use it.

So I'm tagging this as confirmed and wontfix - it really is a wontfix
bug, because it is impossible to fix to start with.

Thanks,

/mjt

Virtual FAT isn't the best option, and it is, thankfully, not used
widely.  There's no reason to keep this bug report at severity level
"important".

Thanks,

/mjt