We have two different systems that are both failing to restore with the same “WIM-based restore failure with error code 60”. The original Winclone images are from iMac 21.5" Late 2012 and they are being restored to brand new iMac 27" 2019 (running 10.14 Mojave). The original iMac’s were running Windows 7 but have been upgraded to Windows 10 and then imaged with a 10.12 Sierra Mac system.
After checking the console log i can see that it verify’s the image and gets to 36% of the file restore and then exits with Code 60. The following log line says “Setting the system to allow sleep…”
Any help would be appreciated, am using Winclone 8 but was also getting the same problems with Winclone 7
Please try switching to block based imaging, create a new image and then try restoring again,
I’m afraid i have already tried that as i am going from an old hard drive based iMac to a new SSD based iMac the block sizes are different, so it would’t allow me to do it. Also tried the direct computer to computer transfer, which obviously gave the same block size issue, so had to go to the WIM file image instead to get around that issue.
I have the same error, and I think this has something to do with WinClone being incompatible with the latest version of Windows.
I have a backup of my BootCamp partition from 19th October 2020, and that restores without a hitch. The same backup image refuses to restore for ANY date after that date, which is the point after which I installed the latest Win10 feature update and WLS2.
BootCamp under BigSur is fragile. Quite often after updating the OS or installing some third party drivers, Windows becomes unbootable, and each time, I try to restore it. Each time the same game: any restore fail, until I go back far enough where I only have the previous Windows version from 19th of October. I restore that, install all the Windows updates, make regular incremental backups, zero errors, until the next time BigSur messes up Windows’ ability to boot, just to realize that once more, all incremental backups past that 19th of October backup fail to restore, even though things were backed up without error.
THIS IS HIGHLY FRUSTRATING!
Switching to a block-based back up IS NO SOLUTION, the whole point of using WinClone as an incremental backup solution for the boot camp partition would be defeated that way. Not interested in dumping 123 GB each time I make a backup, and keep generations of these backups…
It’s not the point to pay for software that’s supposed to do a thing, and then when it doesn’t work, be told “Ah, just don’t use that feature you paid for…”
Also, frankly, I don’t understand how there can be an error in the first place. It’s supposedly “file based backup”. How hard is it to copy a file from one place to another?
We’re not talking about Windows not booting after a restore, that (albeit not kosher), would be a different matter, but a backup restore should simply dump the damn files into place, and unless it runs out of disk space (which is not the case here), there’s no room for errors here, it’s in the “just write the damn file” category of things. How hard can that be? The only thing I could possibly imagine, that WSL exceeds some limit like max. file path length or something like that. But if Win10 has no problem with it, neither should WinClone.
Also, if we have incremental backup, why can’t we have incremental restore? Instead of nuking an entire partition, some file system rendered unbootable by some quirk in BigSur or some third party software, shouldn’t have to be nuked. WinClone could simply traverse the file system hierarchy and replace files that differ with those from the last backup, and ask to delete anything that’s extraneous. One would think that what was once bootable should be again bootable.
So, to reply to my own message, turns out with logging turned on, I could find this beauty of an error message:
2021-02-01T15:27:38+01:00:[ERROR]
2021-02-01T15:27:38+01:00:Failed to set DOS name of "/Users/System Administrator/AppData/Local/Packages/KaliLinux.54290C8133FEE_ey8k8hqnwqnmg/LocalState/rootfs/usr/src/linux-headers-5.9.0-kali4-amd64/include/config/drm/dp/aux" in NTFS volume: Invalid argument
2021-02-01T15:27:41+01:00:ERROR:
2021-02-01T15:27:41+01:00:Exiting with error code 60:
Failed to set short name on extracted file.
2021-02-01T15:27:41+01:00:Last message repeated 3 times
2021-02-01T15:27:41+01:00:Helper tool error: WIM-based restore failure with error code 60
2021-02-01T15:27:42+01:00:Error Error Domain=TaskError Code=1 "WIM-based restore failure with error code 60" UserInfo={standardError=
[ERROR] Failed to set DOS name of "/Users/System Administrator/AppData/Local/Packages/KaliLinux.54290C8133FEE_ey8k8hqnwqnmg/LocalState/rootfs/usr/src/linux-headers-5.9.0-kali4-amd64/include/config/drm/dp/aux" in NTFS volume: Invalid argument
ERROR: Exiting with error code 60:
Failed to set short name on extracted file.
, standardOutput=
So it seems I wasn’t too far off with my speculation about path name too long or something along these lines. It’s not clear what exactly the issue is with “setting the DOS name” of the file in question. But it’s OBVIOUSLY A BUG. Because the backup and the backup container both pass verification, and the Windows System in question was functioning as was WSL with the corresponding Kali System.
Now here’s what’s really bugging me: besides the fact that there’s a bug in the first place, there’s no option to IGNORE ERRORs.
In this case, I could simply restore ignoring the errors, run windows, delete the Kali package, and reinstall it. This would certainly a lot faster than installing a many months old backup, and redoing all the work of updates and software installations that happened since then from scratch.
That said: what’s the chance of getting this bug fixed within reasonable time?
This issue is usually caused by bad metadata on the file that causes the failure. We know what causes the corruption but are looking for ways to detect it and warn.
tim
Thanks, for the info. What exactly do you mean by bad meta-data? I’m confused…
Since I can essentially arbitrarily recreate this issue, by installing WSL with Kali Linux (plus a bunch of linux software packages), it would seem there’s a fundamental issue with WSL and Win10, not some fluke incident.
Also, what good would a warning do me? It’s not like I can change what is getting installed on my disk, and I must back up THAT, and not some fantasy configuration. So a warning would only tell me, that WinClone can’t do what I need it for, which is quite obvious without a warning.
Also, is there a way of telling the restore to just ignore the error and go marching on? If there’s a command line tool, that’s OK, too.
I just want to dump it on disk any which way.