UTM should warn before deleting orphaned drives #3587
Comments
|
It's because of the orphaned drive cleanup. You need to quit UTM before messing with drives. |
|
To be clear: always quit your VM management system before manually messing with VM containers. This applies to VirtualBox, VMWare Fusion and Parallels Desktop too. That said, I've whipped up a little app that rebuilds an image with the compression and qcow2 conversion flags enabled, and then renames the original image and replaces it with the new compressed version. It's living on the edge in the case of image corruption during conversion, but it works for me. If others are interested, I can make it available. It comes with instructions for how to zero out the drive image prior to compressing, for a few different guest OSes. I could even make a version of it that only requires you to drag a .utmconfig file onto it instead of an image file and ensures UTM.app is quit before it runs, if there's enough interest. |
|
On Sun Feb 6, 2022 at 8:29 AM +08, Em Adespoton wrote:
That said, I've whipped up a little app that rebuilds an image with the compression and qcow2 conversion flags enabled, and then renames the original image and replaces it with the new compressed version. It's living on the edge in the case of image corruption during conversion, but it works for me. If others are interested, I can make it available. It comes with instructions for how to zero out the drive image prior to compressing, for a few different guest OSes.
That would be quite interesting. Can you please share it (source code
preferrably)?
I could even make a version of it that only requires you to drag a .utmconfig file onto it instead of an image file and ensures UTM.app is quit before it runs, if there's enough interest.
I'm not sure if that would be doable, because I don't know if dragging a
folder gives access to all contents recursively in the folder.
|
Obviously it doesn’t surprise me one bit that there is an excuse for this so readily available. This is the first I’ve heard about orphaned drives and their cleanup however. Since we’re doing the “just to be clear” thing. Yep. I totally quitted UTM before messing with any of this. But that didn’t stop me from going back in again just to double check there were no shrinking options within the GUI as I was spending forever trying to work out why the qemu-img binary that’s included in the frameworks folder won’t run despite lipo telling me it’s a universal binary 😂 I’m not desperately concerned as the only thing I really had in Windows was a midi controller mapping file and I can probably re-read that from the midi device once I’ve reinstalled windows and it’s my fault and nobody else’s that I don’t have a backup. But I don’t really think it’s good form for a piece of software to delete a 100GB file that wasn’t even of the correct type (it wasn’t a qcow2 file remember, it was just a randomly named file) without any kind of warning. But I guess that’s the Mac way. It “just works”. I think more important is this. I don’t remember if the FAQ was on discord, or in a website associated with UTM but the ‘zero out the drive and clone it to shrink it’ process was recommended somewhere along the line. That really needs a big fat warning in those instructions. The next person to lose an orphaned drive without any form of warning could have a tonne of critical files on that orphaned drive! Orphaned or not, data loss should come with a warning of what is about to happen. |
|
On Sun Feb 6, 2022 at 9:18 AM +08, Martin White wrote:
> It's because of the orphaned drive cleanup. You need to quit UTM before messing with drives.
Obviously it doesn’t surprise me one bit that there is an excuse for this so readily available. This is the first I’ve heard about orphaned drives and their cleanup however.
Sorry if this sounded rude, and yes you're correct that it isn't
documented anywhere. It's just in the code.
Since we’re doing the “just to be clear” thing. Yep. I totally quitted UTM before messing with any of this. But that didn’t stop me from going back in again just to double check there were no shrinking options within the GUI as I was spending forever trying to work out why the qemu-img binary that’s included in the frameworks folder won’t run despite lipo telling me it’s a universal binary 😂
I can't remember the exact details, but I think the problem is that the
qemu used in UTM is patched such that all the commands are built as
shared libraries and directly called from the code. They're not meant to
be used externally.
I’m not desperately concerned as the only thing I really had in Windows was a midi controller mapping file and I can probably re-read that from the midi device once I’ve reinstalled windows and it’s my fault and nobody else’s that I don’t have a backup. But I don’t really think it’s good form for a piece of software to delete a 100GB file that wasn’t even of the correct type (it wasn’t a qcow2 file remember, it was just a randomly named file) without any kind of warning. But I guess that’s the Mac way. It “just works”.
Basically the way the orphaned drives detector works is it does a
directory list of the Images folder inside the .utm, and compares it to
the list of drives in the config.plist, and if they don't match it
deletes (I think, haven't looked too closely at that code recently)
I suppose if you change the qemu-img args to output the shrunk image to
a different folder, outside of the .utm bundle, the it shouldn't get
deleted. (Then **ensure UTM is quit** and and move the shrunk image back
to the correct folder, with **the exact same name** as the original
image)
I think more important is this. I don’t remember if the FAQ was on discord, or in a website associated with UTM but the ‘zero out the drive and clone it to shrink it’ process was recommended somewhere along the line. That really needs a big fat warning in those instructions. The next person to lose an orphaned drive without any form of warning could have a tonne of critical files on that orphaned drive!
Yes, there should be a "Possible data loss" warning on the wiki page
about shrinking drives.
Orphaned or not, data loss should come with a warning of what is about to happen.
Yes, there probably should be some confirmation before deleting orphaned
drives.
|
I'll share it on my github page once I've cleaned it up for public consumption. It's a shell script inside a platypus app shell, so to fiddle with it you just have to view the Resources folder and mess with the plist and the script.
It's doable. If I'm making a version specifically for UTM (I use the current one with vanilla QEMU too), then I can just make it do $1/Images/*.qcow2 (or even $1/Images/* or ~/Library/Containers/com.utmapp.UTM/Data/Documents/*/Images/* if people are OK with it converting EVERY file in the Images dir to qcow2. |
osy
changed the title
|
I still think this is a bug, not an enhancement and the title should not have been changed from what it was. The orphaned disk code shouldn't be deleting files that are not disk image files. How is that not a bug? Also, if going to the effort of producing a warning before deleting orphaned drives ("Warning the following drives are no longer used and will be deleted") then providing the option to cancel the orphan delete would be ideal. It's not critical though because if you're inside the bundle messing about then you are meant to know what you're doing and this warning before doing the actual delete would give you the chance to move or rename the file before clicking OK. Of course, in that event the orphan code then also needs to be able to cope with the fact the file it is expecting to delete could very well not be there. It's messy but I do think it's important. |
|
The thing is you shouldn’t be modifying files in the bundle. Sandboxed apps are not designed that way. But I agree there needs to be some warning when destructive action takes place. |
|
“Orphaned files have been found in your VM configuration. Would you like to delete them or re-add them? Are you sure?
…-Em
On Feb 6, 2022, at 9:33 AM, osy ***@***.***> wrote:
The thing is you shouldn’t be modifying files in the bundle. Sandboxed apps are not designed that way. But I agree there needs to be some warning when destructive action takes place.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
If only there were some other way to reclaim disk space without following the instructions in the FAQ. It's really not unusual for VMs to be used to experiment. In this case I tried out some FPGA development tools and wanted to reclaim the 20GB after it didn't work out and I uninstalled the tools. |
that is planned in #3460 |
|
New plan is to remove orphaned data cleanup by default (exception being drive images stored in /tmp) and instead delete it as part of the cleanup operation as part of #3460 |
Describe the issue
UTM will delete an image file if it is renamed when you go into and back out of the disk settings. Guess how I know!
I was in the process of reclaiming disk space on my Windows disk by using sdelete in the guest and then manually cloning the disk with
qemu-imgas per the related issue below. I had got to the point of renaming the disk with a ".org" extension but had not run qemu-img yet. I wanted to just check something so I went into the disk settings for the VM and into the disk I was working on. I didn't do anything, and I even clicked "Cancel", not "Save" but as I came out of the disk settings, UTM deleted the renamed file. Sadly, the disk file was excluded from my daily backup due to it's size so it's time to reinstall Windows - my bad!Sort of related issue: #3460
Configuration
Debug log
qemu_debug.log
Upload VM
config.plist.txt
The text was updated successfully, but these errors were encountered: