Unable to open "D:\windows 10 x64 - Cpp\Windows 10 x64-000009.vmdk":
The system cannot find the file specified.
I found the file "D:\Windows 10 x64 - Cpp\Windows 10 x64-000009-s010.vmdk" on the antivirus but doesnt restore it.
I had autospanshot enable, but on the workstation they dont work.
Does have anyway of run the system even with a snap ?
What you may do is to exclude *.vm* files from being scanned by your AV to avoid such issues in the future.
For the current issue, please run:
dir "D:\windows 10 x64 - Cpp\*.*" /one > filelist1.txt
dir "D:\Windows 10 x64 - Cópia\*.*" /one > filelist2.txt
Then compress/zip these two files, and attach the .zip archive to your next reply.
André
It's not only "Windows 10 x64-000009-s010.vmdk", but also "Windows 10 x64-000011-s010.vmdk" that's missing.
In addition to this "Windows 10 x64-000010.vmdk" seems to be orphaned, and "Windows 10 x64-000011.vmdk" has a wrong size (is most likely corrupt).
Please compress/zip all .vmdk files without "s0xx" in their names, and attach the .zip archive to your next reply.
Unless already done, I strongly recommend that you backup the VMs files/folder while I'm looking at the .vmdk files.
André
This unfortunately looks worse than expected. It looks like you went back an forth in the snapshot tree, and for some snapshot chains broke. It even seems that files have been renamed.
The latest snapshot chain that should work - at least from a metadata point of view is "Windows 10 x64-000002.vmdk" (18/12/2020).
Snapshot-Tree: Base - 1 - 8 - 14 - 12 - 2
Another snapshot chain that I found terminates with "Windows 10 x64-000006.vmdk" (21/09/2020).
Snapshot-Tree: Base - 3 - 5 - 6
Both chains have the same parent, i.e. are linked clones of "D:\Windows 10\Windows 10 x64.vmdk".
If you can afford the data loss, you may set the virtual disk's file name in the VM's configuration (.vmx) file to one of these .vmdk file names.
Please remember to close VMware Workstation prior to editing the .vmx file!!!
Trying to fix the snapshot chain otherwise would be a hit-or-miss, and would most likely result in a corrupted guest file system.
André
Andre - the basedisk is missing .... so we will fake one and then extract the readable data from both chains ....