virtualbox.org

Ok, to make things more clear here, as I've just read this thread and I'm at a loss somewhere, we need some clear questions on what you want to accomplish and why, Dirki. Here are some things I understand what you want:

• Save program settings, like preferences in Office and Firefox, on a general location so you can point both the Host and Guest to one location and have the same settings on both systems.
• Keep track of every file and registry key that are changed while working in the VM.
• Share files and other documents between the VM and Host, so you can download them in a so called sandbox system that can break without causing harm to your Host.

Now, going from these three points, there are a few things that can and cannot be done.
The first is really hard to do, because you face the problem Fixedwheel addresses, corruption of the files. These programs are made to have exclusive control on their config files. If you open Firefox on the Host and Guest at the same time, things can go horribly wrong. Office stores most of it's settings in the registry, something you can't share.
The other problem he noted, coming from compilers, is a bit different. When you read and write a file, it's saved in a temporary cache for fast access. This cache is written to disk when needed, but compilers constantly read and write from the disk. If the cache is not written when the compiler needs the file from disk, to, let's say, change something, the changes can be lost because the cache overwrites the changes that were just made. This is a problem when using Shared Folders, normal hard drives don't really have this problem because the OS knows where the most recent version of a file is, in cache or on disk.

The second point, keeping track of changes, can be easily done with monitoring programs. There are some more advanced programs that can save all these changes in a database. More simple programs are uninstall help programs. Just check Google for it, you will get plenty of results. It comes down to starting the monitoring of the system when you execute an installer. After the install is finished, you stop the monitoring again and you get a log with all changes made during the run.

The third and last option, to exchange files between the Host and Guest has been explained a lot on these forums already. Also the dangers of possible malware like viruses that could infect the Host from the Guest.
The basic function, sharing files, is nothing more than what you would do with two physical machines connected with each other over the network. You define a folder you want to share and the privileges on it (read only, or read and write). It's never a good idea to share a complete drive, unless you have a very good reason for it. Never, ever share the entire OS drive, that's asking for trouble.
For the best sandbox environment, you create a folder somewhere, let's say C:\Share, and you put the files you want to share in that folder. You can then from the Guest put files in that folder for the Host, and put files from the Host to the Guest. If you use copies, you will still have a backup of the original file in case you get a corrupt file or you make a mistake (e.g. remove it).

Another thing, don't forget to read the User Manual, and the VirtualBox FAQ for some more information.

I have to say that as a developer I doubt this claim that multiple file { open, write, close } iterations can cause systematic corruption. Any such write request must pass through several API layers, ultimately reaching a common API on the host, and if that common API was systemetically screwing this up it would be obvious with every use of shared folders. This argues that the bug must be introduced in an earlier API layer - and the most obviously likely early stage at which such a bug might be introduced is in the authors own code, since it sounds very much like the author in the thread referenced by fixedwheel got a buffer length wrong in a write call, or perhaps there's a buffer length bug in a perl library he uses.

However, it's easy to experiment, so I just knocked up a little Win32 C program to run inside an XP VM, doing precisely the above (I did 40 writes of a line of text, closing and reopening the file for each write, with a seek to EOF at each open). The target file was in a shared folder... and there was no corruption.

I'm a teeny bit uncomfortable doing this test with text files, since text file libraries sometimes use EOF markers like ^Z, meaning that the seek to EOF call might ignore bytes added post EOF mark... so let me just try something else. Ok, I just modified the code to use normal binary file I/O to create the file, so no possibility that a text file library was hiding the problem... and still no corruption.

Other than the one anecdote mentioned, what other evidence is there for this bug?

There is no evidence for the bug, except the one you mentioned, wrong code by the writer, and in this case, someone who compiles his own code, not the code of VB.

As for my own explanation, it's pure hypothetical, I have no experience with these kind of things. I was only pointing out IF one would occur, why it might happen. I never intended to write it as being a fact that it can happen all the time if you're not careful. However, there is one such case where it did happen, and that was with the introduction of the EXT4 file system in the 2.6.28 kernel for Linux. The fault there was that all the software developers wrote their programs on the basis of the EXT3 system, where files are written to disk at least every 5 minutes, and now it didn't do that any more. You can find the whole story on the web, no need for me to write it down again.

Thank you very much, Sasquatch.

And sorry for my insufficient information.

Sasquatch wrote:

• Save program settings, like preferences in Office and Firefox, on a general location so you can point both the Host and Guest to one location and have the same settings on both systems.

Yes, this is a kind of using I may be will also do.

But mainly I would like to use it this way: install like usual for example Office 2007 on a VM (not anywhere else), only one time. All my personal data, files (which e.g. control settings of Office, Outlook, Word etc., e.g. for the tool bars created in Outlook, Word, accounts, folders and many more), folders (which contain the .pst file containing all e-mails, messages, addresses, address book and many more) belonging to Office (installed now on a VM) are stored on my primary system, let’s suppose in one single folder containing sub folders containing all these personal data, files (which do not may get corrupted / lost, what might happen with Office I do not care) belonging to Office. And now I point the installation of Office on the VM to all these "personal" folders already being on e.g. H: (the way I would do it without using a virtual box) by making these folders shared folders.

These programs are made to have exclusive control on their config files. If you open Firefox on the Host and Guest at the same time, things can go horribly wrong.

Yes, I see, if I would run at least 2 installations (using the same personal data, files existing only once) of the same program (e.g. 2 installations of Firefox, one of them on the VM the other one on the host, both using the same profiles [containing personal settings]) on a VM and the host (what is not yet intended), I would open only one of the same programs at a time, at least, if they would use the same data / files. At the moment I have these personal data, files stored on another hard disk, so Office is on C: the customized data, settings, files on H:.

The other problem he noted, coming from compilers, is a bit different. When you read and write a file, it's saved in a temporary cache for fast access. This cache is written to disk when needed, but compilers constantly read and write from the disk. If the cache is not written when the compiler needs the file from disk, to, let's say, change something, the changes can be lost because the cache overwrites the changes that were just made. This is a problem when using Shared Folders, normal hard drives don't really have this problem because the OS knows where the most recent version of a file is, in cache or on disk.

I assume, this doesn't refer to using an application only existing once on all systems. And as there doesn't seem to be an evidence for existing of this bug mentioned here, I guess, I can / should disregard it anyway.

The second point, keeping track of changes, can be easily done with monitoring programs.

Yes, okay, I will have a look, try to find a good one.

The third and last option, to exchange files between the Host and Guest has been explained a lot on these forums already.

Yes, just exchanging data using shared folder seems to be very easy, I see, just like it is on a real network.

Another thing, don't forget to read the User Manual, and the VirtualBox FAQ for some more information.

Yes, I don't. I will go on reading it.

Many thanks for your help, nice greetings, Dirk

Just to make things clear, you can't save the Office settings on a different location, because they are not only saved on disk, but in registry too. It's also not advised, nor of any use or other advantage, to have the settings away from your application data folder to a common share. A lot of programs can break with that setup or have really strange behaviour. If you do anything like this, don't come here to ask for help, because I just warned out about the possible consequences. I'm pretty sure any other forum would respond in the same way, moving the files to a network share is not advised, unless your entire profile resides there like in domain situations. Then, and only then can things work.

since you're asking here if it can be done and how, I wonder if you have the skills/knowledge to actually make it work.

Thank you, Sasquatch.

Just to make things clear, you can't save the Office settings on a different location, because they are not only saved on disk, but in registry too.

Hmmm, I am not quite sure to understand right, at the moment the Office settings, personal data / files are stored on another hard disk than Office is installed on. But I guess you refer to shared folders being on different systems only.

If you do anything like this, don't come here to ask for help, because I just warned out about the possible consequences.

Okay okay, when you say it won't work, I will not do it...

since you're asking here if it can be done and how, I wonder if you have the skills/knowledge to actually make it work.

Meanwhile I am wondering that also. Until now I had thought, it wouldn't be that difficulty to do: just point Office to these shared folders like it is done on my current system, that's it, but I see it is not that easy.

Many thanks again, nice greetings, Dirk