Mounting VMDK Causes system to become unresponsive
Status: Inactive
Brought to you by:
w77
Menu
▾
▴
WinXP3 .NET v4.0.30319 installed
Copying two old Microsoft Backup Archives (WinXP1 as a guess 2004) (without .bkf extension) to VMDK disk the system becomes unresponsive and freezes becoming unresponsive didn't leave it to crash. Needing me to press restart on PC Case to reset the PC. No Task Manager or Process Explorer would help or open to see other details. Not nice for any software to do this.
Nothing is copied to the VMDK which I attach. I have tried other VMDK same result. VMDK mounted using windows context and selecting Drive Z that for read-write with HardDisk already selected. Open drive from explorer and copy the files using drag and drop.
After trying this I opened files using VmWare 7.1.6 Mount or disconnect virtual disks and copied the files as above as normally should be able to do.
Why the need to log-in to post ? Had to agree with some Sourceforge privacy crap to do so heck knows what I agreed to. Sourceforge is shit.
You hear me Sourceforge Shitty site ? I bet you do - shitbags.
I confirm the issue. On XP SP3, copying a small file (a few KB) to this volume succeeds, but a file of several MB fails. I can see in the task manager that DiscUtilsDevio does nothing, everything seems frozen.
The issue does not occur on Windows Vista, 7 and 10.
On 8.1, I get other issues... I cannot open the file to check its partitions.
This will be something to fix for Olof...
Thanks for the report. I can verify this to be a problem on XP. Not sure how or when it could fixed though. It is an issue with a file system call deadlock that can on XP practically only be avoided by opening image file in non-cached mode. To implement that in DiscUtils image file support libraries would be a pretty large amount of work and would probably need some major redesign in some places to avoid things that cannot be done in non-cached mode, such as reading and writing other than multiple of sector sized data etc.
So, I'll leave this as a known issue for now. Maybe we could come back to it at some point if someone has some better ideas about how to solve it.
The above terse remark I find born from cookies consent.
@ Sourceforge we cannot sign in without cookies. As te browser has them to login that aready means they are excepted. We cannot login with accepting them in the browser.
This makes Sourceforge idiots asking for something that is not needed to be asked ever.
No further comment will be made about this here on imDisk forum.