wsl --unregister <Distro> should warn users that their data will be permanently deleted.

jgarzagu commented 1 year ago

Windows Version

Microsoft Windows [Version 10.0.22621.1413]

WSL Version

1.1.6.0

Are you using WSL 1 or WSL 2?

[X] WSL 2
[ ] WSL 1

Kernel Version

5.15.90.1

Distro Version

Ubuntu 20.04

Other Software

No response

Repro Steps

wsl --unregister

Expected Behavior

After running the command line, the program should ask the user to answer yes or no regarding the permanent removal of the distribution.

Example:

wsl --unregister <Distro>
Are you sure you want to permanently delete <Distro>? (yes/no)

This will prevent more users from mistakenly deleting all their information as it has been reported on multiple occasions.

For automation purposes, an extra flag should be added to skip the message (e.g., --force).

Example:

wsl --unregister <Distro> --force

Actual Behavior

No warnings are prompt to the user. WSL 2 deletes the distribution without asking the user.

Diagnostic Logs

No response

aki-k commented 1 year ago

Isn't this description enough to tell you what it does?

--unregister <Distro>
    Unregisters the distribution and **deletes the root filesystem**.

jgarzagu commented 1 year ago

@aki-k In my opinion, I think is not enough from the human-computer interaction perspective.

The commands should be easy to understand even if you don't read the help options for the commands. That's what separates great products from average products. Why do people prefer the Linux terminal over PowerShell in the first place? It is the interaction design, the user experience. The user experience is not just for interfaces. Linux commands are intuitive, and you don't even need to read what all the commands do to understand their functionality.

wsl --unregister not only fails to provide a good user experience, but it's becoming more dangerous as WLS is becoming more adopted. First, unregister is something that users doesn't associate with delete. A better name perhaps would be wsl --delete. Second, I've seen more tutorials popping up to fix problems that use wls --unregister and many unexperienced users who are following the tutorials have reported their distros and all data deleted by accident.

An example is issue #8525, I also followed those instructions at 1 am and accidentally deleted my distro. It was my mistake, yes, but I never expected a command that would delete everything without even asking, and I was unable to associate unregister with delete. My Ph.D. dissertation was there...

Please, don't get me wrong, I really like the WSL tools and what the developers are creating, and I want the tools to improve. 🙂

aki-k commented 1 year ago

@jgarzagu Yes, you're right and sorry for your loss but the fact still applies that you should understand the commands you run. I actually ran into a Powershell command that didn't ask for confirmation even though I used -Confim:$true and just formatted a filesystem.

PS > Format-Volume -FileSystem FAT32 -NewFileSystemLabel "SYSTEM" -DriveLetter "X" -Confirm:$true

Edit: I sent feedback to Microsoft through the Feedback Hub about Format-Volume

NotTheDr01ds commented 1 year ago

I think this is a great idea. I'd even go so far as to say that the prompt should require you to type the name of the distribution to confirm. I spin up and --unregister distributions quite frequently, and I'm still paranoid I'm going to delete the wrong one accidentally.

I like the idea of --force for automation.

Only problem, of course, is that the change would break existing applications that automate --unregister.

NotTheDr01ds commented 1 year ago

As an aside, the other thing I'd love to see related to preventing data-loss is the ability to separately mount additional VHDX's automatically through /etc/wsl.conf (per distribution) and .wslconfig (for all distributions).

The mount needs to be available before the shell is available so that we can mount home directories separate from the distribution itself. Or (for shared mounts) have a directory of shared scripts that might be called from something like ~/.bashrc.

Having my home files and important scripts "safe" in another filesystem mount would go a long way towards relieving my paranoia about --unregistering :-).

NotTheDr01ds commented 1 year ago

I believe in another thread on the topic, @OneBlue mention the same compatibility issues I did above with automation. Some thoughts on that:

Easiest and most compatible: Perhaps add a warning message, with a delay of 10 seconds (or more) before the distribution is removed. During that time, the user can Ctrl+C (or another key) to abort, but it will continue automatically if not. This would allow existing automations to proceed unmodified.
Add a --force option but provide a deprecation period for the old functionality (perhaps in combination with the message/delay above). After the deprecation period, switch to asking for confirmation unless --force is used.
Have wsl --unregister default to moving the ext4.vhdx to the Windows Recycle bin or <userprofile>\temp. Remove it with wsl --unregister --delete (or one-step with wsl --unregister --force).

3kh0 commented 1 year ago

That should be a given that the data would be deleted...

GiggleMonster commented 1 year ago

So there's no way to get my kali linux distro data back after unregistering?

3kh0 commented 1 year ago

Yes, it would have been deleted.

ryuheechul commented 1 year ago

I'm actually a bit shocked after finding out how --unregiser works...

--shutdown works without confirmation and I'm fine with that because the consequences for this is smaller, usually just need to start the distro again and that's it.

But the consequences for --unregistar is much greater so it should be not be trivial to do this irreversible action and some UX additions somethings like below should be added:

requires more explicit options like --yes (similar suggested at the top)
- (or --force or user password)
interactive confirmation when no --yes flag is provided

Another approach for improving this workflow would be make this deletion a soft delete not a hard delete so that it's possible to undo it.

So why the safety mechanism for --shutdown and --unregistar is the same? I think it shouldn't be.

I think this is an UX issue that is bigger threat for people who kind of treats WSL as their "main brain" and using Windows for just the shell. If WSL is promoting the idea of not needing to install Linux into bare metal for personal computing, this one should be improved.

jacobus commented 1 year ago

This definitely needs to be fixed. Ideas mentioned above for adding a --force parameter, and having a further confirmation is sorely needed. The term (unregister) makes it sound like that you can unregister and register distributions as needed. I was in a hurry and wanted to swop out a troublesome distribution with another and also used --unregister with unexpected and bad consequences. Windows users are accustomed that dangerous commands provide confirmation before running. One should always take an approach of least surprise when developing user interfaces.

megapro17 commented 1 year ago

Wow, that's a really terrible user experince. It is even possible to unregister without deleting image?

yilmazdurmaz commented 1 year ago

"register"ing something has the meaning of acknowledging the existence of something and act accordingly. Thus "unregister" should just remove only the settings needed to run a distro (the acknowledgement) and do not remove its existence for any reason, but instead give details about what to do.

I install a distribution, such as Ubuntu-22.04, only to export it as a template, and then import the same file as many times as I need for different purposes. I remove them when their purpose is met, yet there are times like system crashes that needs a reinstalling the whole system. I had this recently and I can now easily import my previous copies. Saved a lot of time.

But if I accidentally forgot this current "unregister" behavior, and do some operations on the disk until I remember the fatality, it won't be possible to recover them anymore. Thus, my vote goes to this post's purpose: don't delete disks without asking first.

GunMetalBull305 commented 10 months ago

We are starting to use WSL for development. Having our devs accidently unregister a distro, could be catastrophic. The "unregister" option should simply remove the distro from the registry, and advise the user to manually delete the files.

That usage pattern would bring WSL more inline with other hypervisors, where "removing" a virtual machine only removes its registration, but leave the files intact.

seyfullahari commented 10 months ago

There is a logical inconsistency between --import-in-place and --unregister options. When a distro is exported as vhdx file and later imported with the --import-in-place option, unregistering it shall not delete the vhdx file by default. There should be an extra option to force delete the vhdx file when imported with --import-in-place.

I, unfortunately, lost a setup I spent a lot of time on. I just wanted to rename my distro. :)

MrStLouis commented 9 months ago

I'm in the exact same boat. I just moved a hardrive from an old PC and wanted to get a few files from an old wsl install. I used the --import-in-place on the 4 different distros I somehow had to find the one that I needed. Now I have 4 distros added and I want to clean them up BUT keep the vhdx files in case I need something else at some point. I dont want to unregister because I dont want to delete them, I just dont care to see them as "installed" right now

AntonOfTheWoods commented 8 months ago

If you have plenty of spare space you can obviously just export then reimport as often as needed but it would definitely be good to be able to "unregister" and have it do just that, rather than completely delete everything.

unregister is patently a horrible verb to use, and clearly doesn't do what most normal speakers of English would expect.

But my guess is that MS never actually expected anyone to do any serious work -> this was just for playing around so you register then unregister your tests when you don't need them anymore. It is almost certain that there is more work going on in WSL than on bare metal Linux installs now, but choices were made back in the day...

diegovilar commented 8 months ago

My workaround is to make the virtual drive readonly before unregistering the distribution. WSL will unregister and silently fail do nuke the file. Beats having to copy or export the file..

it's still a workaround, of course. "Unregister" is so misleading. Imagine if "unfollow" secretly meant unfollow, block and report at the same time. Bad joke

GunMetalBull305 commented 7 months ago

This is becoming a major detractor for adopting WSL in my developer group. The change required seems straight forward, and would substantially reduce accidental data loss.

If the project contributors will not address this issue, please state so, and close the this ticket. Otherwise, please stop closing duplicate tickets, if you have no intention of addressing this one.

aki-k commented 7 months ago

@GunMetalBull305 "major detractor" I never run commands where I don't know what the options do. How can this be so difficult for your group?

yilmazdurmaz commented 7 months ago

@GunMetalBull305 "major detractor" I never run commands where I don't know what the options do. How can this be so difficult for your group?

You might be a very careful person about such issues. Please, do not think of us lower beings anything close to your standards, and try to feel our pain and have sympathy with your extraordinary existence.

aki-k commented 7 months ago

@yilmazdurmaz I agree that it is a problem that --unregister is missing the confirmation, but it's bad practice to run commands without checking out what the options do, like that recursive rm

GunMetalBull305 commented 7 months ago

@aki-k thanks for agreeing, and for your very constructive and helpful feedback. 👍

diegovilar commented 7 months ago

@yilmazdurmaz I agree that it is a problem that --unregister is missing the confirmation, but it's bad practice to run commands without checking out what the options do, like that recursive rm

I'd say that it's also bad practice to implement a nuke command and name it slap, but maybe that's just me...

The point is that the name of a command, a function, an option, etc. should transmit as much as possible what it will do. Additional actions should come as additional flags, not as a surprise. Nobody expects "unregister" to mean "unregister and delete". Delete, such a destructive and irreversible thing, should be a flag, or at least require confirmation. What it should never be is an unexpected side effect.

Saying that the problem is that the user did not read the documentation is quite frankly outrageous. We name things so we can rapidly understand what they are or do. If not, let's just rename "unregister" to some nonsense word like xqhs72d and I assure you nobody will ever have any expectations about what it does and will refer to the manual. While at it, we could also remove labels from buttons and make the user go to the manual to find out what the third button from the left does...

yilmazdurmaz commented 7 months ago

@aki-k there is a reason (almost?) every language has the words to mean "distraction" and "accident". No matter how careful you are, accidents are bound to happen.

But you can, as a programmer, lower the probability of these accidents by naming your functions with conveniently matching functionality. Another way is putting warnings and confirmation prompts to dangerous functions.

Instead of expecting maybe millions of users to be always on the edge when using your program, making a slight change on the program itself to minimize accidents should always be the preferred way.

Our suggestions so far are:

"--unregister" only unregisters as the name suggest and does not delete the image
- or moves the image to recycle bin
- adding another flag, such as "--force" or "--delete", to actually delete the image
- instead of above ones, adding a confirmation prompt that emphasizes it will delete the image.
- umm, was there other ways, sorry I forget while writing,

AntonOfTheWoods commented 7 months ago

Microsoft is a large organisation and they change stuff that gets into production very, very rarely. The likelihood of this getting changed is very close to zero, even if they did have devs who cared/agreed. Sure, we can rant about it but they simply won't do anything about it, so I guess discussing it mainly helps our inner troll.

GunMetalBull305 commented 7 months ago

@aki-k there is a reason (almost?) every language has the words to mean "distraction" and "accident". No matter how careful you are, accidents are bound to happen.

But you can, as a programmer, lower the probability of these accidents by naming your functions with conveniently matching functionality. Another way is putting warnings and confirmation prompts to dangerous functions.

Instead of expecting maybe millions of users to be always on the edge when using your program, making a slight change on the program itself to minimize accidents should always be the preferred way.

Our suggestions so far are:

"--unregister" only unregisters as the name suggest and does not delete the image

or moves the image to recycle bin

adding another flag, such as "--force" or "--delete", to actually delete the image

instead of above ones, adding a confirmation prompt that emphasizes it will delete the image.

umm, was there other ways, sorry I forget while writing,

Those were the options I was thinking of as well. Would be very helpful.

aki-k commented 7 months ago

Microsoft is a large organisation and they change stuff that gets into production very, very rarely. The likelihood of this getting changed is very close to zero, even if they did have devs who cared/agreed.

Here's a $10,000 (maybe more) question: does the following Powershell command confirm from the user whether he wants to format the X: volume?

PS > Format-Volume -DriveLetter X -FileSystem NTFS -NewFileSystemLabel "NTFS" -Confirm:$True

( Reference: https://learn.microsoft.com/en-us/powershell/module/storage/format-volume )

GunMetalBull305 commented 7 months ago

Microsoft is a large organisation and they change stuff that gets into production very, very rarely. The likelihood of this getting changed is very close to zero, even if they did have devs who cared/agreed.

Here's a $10,000 (maybe more) question: does the following Powershell command confirm from the user whether he wants to format the X: volume?
PS > Format-Volume -DriveLetter X -FileSystem NTFS -NewFileSystemLabel "NTFS" -Confirm:$True
( Reference: https://learn.microsoft.com/en-us/powershell/module/storage/format-volume )

I'm honestly not sure what you are trying to do here. Your comments have contributed nothing, except a little entertainment, to this ticket. We understand and appreciate your viewpoint. There is nothing else you need to say.

aki-k commented 7 months ago

@GunMetalBull305 honestly, this ticket shouldn't even have been opened in the first place. and seeing microsoft's non-existing response, this probably won't ever be resolved. happy hunting, captain

GunMetalBull305 commented 7 months ago

@aki-k thanks again for your wisdom.

ohofherr commented 6 months ago

I'm also shocked to find out how wsl --unregister works. It should be renamed to --delete, --unregister should keep the image. A new option --export-in-place that reverses --import-in-place wouldn't make much sense from the naming.

ChickenIQ commented 5 months ago

Guess who just found this out the hard way...

I had backups, but the command should just unregister the distro, optionally removing the data with something like "--purge"

atdiar commented 2 months ago

Yup. Followed blindly some online tips although it corssed my mind that stuff could be deleted. Scrolled after the fact to see people warning that it would delete everything smh

So now, not only is the initial problem not solved (blank black screen with vcxsrv) but I've lost some stuff. Fortunately the most importan (recent code) had been uploaded to github.

Should definitely add some sort of confirmation. -rm -rf silly

microsoft / WSL