I think I may have found a fix for this issue. I'd like to work on this.

This bug seems to come from this function.

func MiniPath() string {
	minikubeHomeEnv := os.Getenv(MinikubeHome)
	if minikubeHomeEnv == "" {
		return filepath.Join(homedir.HomeDir(), ".minikube")
	}
	if filepath.Base(minikubeHomeEnv) == ".minikube" {
		return minikubeHomeEnv
	}

	legacyMinikubeHome := filepath.Join(minikubeHomeEnv, ".minikube")
	if _, err := os.Stat(legacyMinikubeHome); !os.IsNotExist(err) {
		return legacyMinikubeHome
	}
	return filepath.Clean(minikubeHomeEnv)
}

The problem is that whether the legacy home directory functionality is used depends on the existence of a directory at $MINIKUBE_HOME/.minikube. If the directory doesn’t exist the $MINIKUBE_HOME is assumed to be the actual home and the ‘.minikube’ directory name is not appended to it. This is what resulted in an unexpected directory deletion.

The pull request that introduced this behavior was intending to make backwards compatibility more convenient but it seems to have caused a bigger problem. The pull request was resolving an issue about the confusing behavior of MiniPath. However, this seems to have created a bigger issue.

I think it would be best to move back to the old version of the code and add some tests that demonstrate the backwards compatible behavior better.

I made a pr with some changes that fix this bug.
/assign

I think we kind of did a mistake in the previous release not to think about this, the rightthing to do is,
in the delete --purge code. we need to Check What folders we are deleting...and if there is any folder other than minikube sub folders we should Warn the user if they wanna proceed.

alternatvely we should enforce users to set their minikube home folder to something that is called .minikube, so in the purge we only delete .minikube folder

I wish there was a way to Tag or label files and folders created by minikube (like when u create a docker resource)

that way we could be 100% sure we deleting only minikube

I think we kind of did a mistake in the previous release not to think about this, the rightthing to do is, in the delete --purge code. we need to Check What folders we are deleting...and if there is any folder other than minikube sub folders we should Warn the user if they wanna proceed.

alternatvely we should enforce users to set their minikube home folder to something that is called .minikube, so in the purge we only delete .minikube folder

It seems like there are two options.

1. Make the program ask the user whether they want to delete their minikube home if it is a non-standard one, or
2. Make the program expect that there is a ".minikube" folder as a child of the specified MINIKUBE_HOME path if the MINIKUBE_HOME path doesn't end with ".minikube."

From what I understand, the goal going forward is to require the base name of the config directory to be ".minikube". Option 1 allows users to use a non-standard directory name for their minikube config. However, option 2 still requires a ".minikube" directory to exist somewhere on someone's system in order for their minikube instance to work.

I think option 2 is more in line with the overall goal of getting everyone switched over having their minikube config directory be named ".minikube". If you go with option 1 it allows people to use a directory named "mini-kube" for their config which would get you further away from the end goal.

I still dont know the right solution but I know for sure we have to add these guard rails regarless of the solution

1- if $HOME dir is the same as "minikube home folder" we should NOT delete it and tell the user they gotta do it manually and be cautious
2- if we notice non minikube sub-directories bellow

$ ls ~/.minikube
addons			certs			machines
ca.crt			config			profiles
ca.key			files			proxy-client-ca.crt
ca.pem			key.pem			proxy-client-ca.key
cache			logs
cert.pem		machine_client.lock

3- would be create a Flag File inside minikube with some signature that shows this folder was created by minikube
the flag could simply ".CREATED_BY_MINIKUBE" and would have the content of the version of minikube that created it...
so all of the folders and subfolders that miinikube creates would have that file.
so in the future (3-4 releases from now ) we could stop delete any folder that does not have the Flag file

however we wont be able to do that in next 1-2 versions because the next version of minikube wont be able to delete the .minikube folder that doesnt have the flag (created by previous versions)

so we should have a main function called "IsItMinikubeCreatedFolder" and we can use option 2 and 3 to verify
and then we can perfrom the delete otherwise we tell them to do manually..

4- We can also check the folders/files listed in 2 and the first time that we create/start the minikube home folder we should Warn them that they have chosen a Non Empty Directory for their home folder.

@afbjorklund @prezha wdyt

I think the way to go is to accept MINIKUBE_HOME as the directory where the .minikube directory is created. There is no reason to let the user chose the ".minikube" part, and deleting MINIKUBE_HOME is wrong as deleting HOME.

There is no need to check the contents of the .minikube directory, it belongs to minikube and users should not keep their files there.

If a user configures MINIKUBE_HOME=/path/to/.minikube, minikube should use the directory /path/to/.minikube/.minikube.

it would be hard to tract which folders and files we (ie, minikube) created and which ones user added/modified in minikube home dir (eg, solutions relying on any filesystem features would be "impossible" to implement for all possible filesystems users might have, also, maintaining some kind of list of files/folders minikube created could be error-prone and unreliable, etc.)

on the other hand, there are cases where we do want minikube home dir completely removed (eg, sometimes that's used to check if it fixes an issue user is facing, in CI to "start from scratch", etc.)

up until v1.34.0 .minikube was the directory where all minikube-related stuff is stored (both from minikube and some from a user - like custom defaults, etc.) and with --purge, a user explicitly requests all of that to be removed

hence, "merging" the minikube-related stuff with other stuff is generally not a good idea

therefore, we could revert the change so that MiniPath() again always returns .minikube as the last element of the minikube home path, ensuring that we're operating within a dedicated folder (traditionally, it was .minikube and we have no reasons to change that)

however, if the only potential issue is while purging, whereas MiniPath() does not return .minikube as the last element of the path (eg, because MINIKUBE_HOME path does not end with .minikube and MINIKUBE_HOME dir does not contain .minikube subdir), we could, in that case, alternatively either:

• request a user to confirm purge request
• add --force flag to the minikube delete command to assume purge request confirmation (eg, also for use in a CI)

Thank you both @nirs and @prezha

based on both above here is what I think,

it is perfectly okay for minikube to have mandatory ".minikube" home folder name so if the user wants to force minikube to use a not .minikube name seems to be a very odd request for not clear reason however they would still have a chance to do that by makiing a symlink.

so I am in favor of reverting the change.

wdyt @spowelljr ?

one thing that would make sense is, if the user Already specified ".minikube" in their ENV we could ignore avoid making a nested .minikube, wdyt @prezha @nirs

btw @nirs I have seen your great contributions to minikube I am greatful for having you around, woudld you like to come to our office hours sometime ? our next one Next monday 11 AM Pacific time

https://minikube.sigs.k8s.io/community/
https://tinyurl.com/minikube-oh

one thing that would make sense is, if the user Already specified ".minikube" in their ENV we could ignore avoid making a nested .minikube, wdyt @prezha @nirs

This is nice to have, but better keep the code simple - we have enough complexity.

This fix should be merged rapidly, as this just deleted the entire contents of my work, including commits i had not pushed.

I had my MINIKUBE_HOME set to a directory i use for all of my work stuff (reason being is that /home/ is a network share and it would be slow to do all of my coding there.) Running minikube delete --purge (which i assumed would be harmless), deleted all of my work. Technically, if someone was particularly absurd (or just set the env variable slightly wrong in a script), this could result in killing a system.

btw @nirs I have seen your great contributions to minikube I am greatful for having you around, woudld you like to come to our office hours sometime ? our next one Next monday 11 AM Pacific time

https://minikube.sigs.k8s.io/community/ https://tinyurl.com/minikube-oh

Thanks, I'll try to join.

one thing that would make sense is, if the user Already specified ".minikube" in their ENV we could ignore avoid making a nested .minikube, wdyt @prezha @nirs

yes, i think that should ok - ie, i if we revert the change, it would be as the previous behavior was:

// MiniPath returns the path to the user's minikube dir
func MiniPath() string {
	minikubeHomeEnv := os.Getenv(MinikubeHome)
	if minikubeHomeEnv == "" {
		return filepath.Join(homedir.HomeDir(), ".minikube")
	}
	if filepath.Base(minikubeHomeEnv) == ".minikube" {
		return minikubeHomeEnv
	}
	return filepath.Join(minikubeHomeEnv, ".minikube")
}