perhaps a removable disk with large ammounts of media 100+ meg for copying in files
(emulated of course) that isnt saved by the save restore
so if you need to put something new in windows click a button in plex86 to emulate an
eject on the system and then you can mount and copy and then turn back on the media
and also be sure to section this out from the cpu capture so that it isnt captured in
save/restore
"Kenneth C. Arnold" wrote:
> According to Eric Laberge (sometime around Fri, Dec 15, 2000 at 06:19:11PM -0500):
> > At 17:19 2000-12-15 -0500, you wrote:
> > >Still don't see why I should be denied access to the raw HD... I modify a
> > >FAT32
> > >partition via mount when I'm running Windows in VMWare....
> >
> > Sorry if what I said was confusing, but my idea is that in order to avoid
> > problems, it should be better not to touch the disk image between a suspend
> > and a resume. If you want to do so, fine, but I strongly suggest you to
> > reboot the guest operating system, in this case, just like you normally
> > would with a real computer. IMHO, mounting a partition while accessing it
> > with another program, like you just said you did with VMWare, isn't a good
> > idea at all, and falls back to the "unsupported" category. As soon as an
> > operating system has any caching mechanism, you screw up everything, this way.
> > The bottom line is: "If you want to change anything from outside the guest,
> > then turn off the guest first, or be prepared for bad things to happen."
>
> I can vouch for this. I copied one small file to my Win98 partition
> while VMWare was suspended (I hadn't gotten samba stuff to work in
> Win98 at that time). It was a small file, but nonetheless when I
> started up the virtual machine, it crashed rather quickly, and the
> ScanDisk on startup took an awfully long time. Now the icon cache is
> totally hosed and the graphics are weird, but that's ok because I
> don't like Windows anyway. But I would _not_ want somebody doing that
> to an ext2fs partition -- I'd sue them for negligent damage to their
> poor helpless computer.
>
> In short, OSes are designed (with very few exceptions) to have
> exclusive access to the system's hardware, including hard drives and
> data on them. Any attempt to circumvent this is playing with fire (as
> Kevin should know by the number of times his machine rebooted during
> early development <g>). With hardware, the fire can be kept to a
> minimum because it is easy to act like hardware had really done what
> it had done. But for filesystems, the OS thinks it can do whatever it
> wants with the filesystem and what was there a second ago is still
> there now (gfs being a very notable exception). Don't argue with it on
> this regard; you'll lose.
>
> --
> Kenneth Arnold <[EMAIL PROTECTED]> / kcarnold / Linux user #180115
> http://arnoldnet.net/~kcarnold/
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
