This is probably common sense, I had a bad feeling before I tried this, but I backed up my VM first so who cares. Anyways... I turned on disk compression in Windows 2000 and let it shrink my HD. Previously it was using 1.8GB, and after that it was somewhere around 1.3GB. Took an hour or so to run. After THAT... I of course ran Parallels Compressor! Well basically it's been running all night and several extra hours... still on the "Preparing for Compacting" stage. The little HD light is blinking away and I guess it's working? I've compacted before this and it only took a few minutes, so I'm guessing Windows drive compression and Parallels Compactor are not exactly the best of friends. Now in the old days of Windows 95... drive compressing simply made one huge file with everything stored inside it. If you booted in DOS or Linux you could see how it was set up. That type of compression should easily work well with Compactor, but I'm guessing Windows 2000 does it differently in a way that's not compatible?
I have the same problem, my VM (VMware) files are file-compressed both inside and outside, i.e. the Windows installation on the VMivs file-compressed and the VM hard disk files as well. My VM hard disk is about 9GB. I terminated a Parallels Compressor after about 14h on the 'Prepare to shrink' stage. I guess it would end never or take weeks if not months. Please, any response from a Parallels expert is much sought after. They should know if it works with file compression or not. I assume there is some kind of deadlock situation in conncection with file-compression. It may even harm the installation. I also think the progress indicator can be improved and some actual time information should be added --or some nice graphical visualisation like file defragmenters have.
Ok, I just did a complete compression on a 20gig in about an hour. IMHO, this is one of those situations where you have a process running in your services that is updating a file on the HD and causeing the compressor to restart the task. I have seen this for years working with windows. Try shutting down all unneeded services and try again
I already stopped all services down to the minimum. I haven't yet tried in Windows safe mode (probably it won't work or only very slow because of unaccelarated disk performance). The problem may be that for some reason the outer file-compression of the virtual disk gets into activity if something "inside" happens, please remember I have file-compressed the OS installation and the VMware files. I do this because I run it on a USB external hard disk and I believe the overhead of compression work will be more than offset by the reduced transfer bandwith. Hope that makes sense. But, if from a technical view, file-compression is no problem, than the reason may be something else .
Do you have any antivirus software installed? To zero unused space and mark it for deletion Compressor creates lots of 2G empty files. Antivirus software may somehow correlate with this. Try to temporarily disable antivirus monitor for time of Compressor session.
Yes, Parallels and Windows are fighting. But there's a simple solution The original poster was correct in assuming that this is a battle between windows drive compression and the parallels compressor. If you watch the root directory (C:\) as this never ending operation is going on, you'll see parallels compressor creating an endless stream of 2GB files. This was the first thing that clued me in. How can there be a dozen 2 GB files on an 8 GB drive??? The answer is obviously that, as fast is parallels compressor is creating these huge files to try to fill all available space, Windows is compressing them down to next to nothing!!! And they can dance that dance for a really long time. The solution: Just go to the Properties tab for the C: drive. Uncheck "Compress drive to save space" and then when it prompts you to apply to "only C:\" or "C:\ and all subfolders", just pick "only C:\". That way, all your other folders remain compressed, as you probably wanted, but the dummy files that parallels creates are *not* compressed. Voila. Process completes successfully.
