Remote content is deleted when client is reinstalled and workspace is re-created

[ADRFranklin]

What happened?
So if the client happens to need to reinstall (due to system failure or similar issues) there is no way to re-import an already existing project on a remote machine. An attempt to re-create the project will in fact make devpod delete the currently existing data, meaning if you were not using git, or had unstaged changes those files are now gone and devpod will now try to re-upload the files what you currently have, and because devpod does not sync file changes down, you end up with lost progression.

What did you expect to happen instead?
I would expect devpod to figure out if an already existing project with the same name exists, and if so, ask the client if they would prefer to use it, or change the workspace name to something else. I also think that when an ssh provider is added, it should go ahead and check if any workspaces already exist on the provider and import those workspaces for the client so they can just continue.

How can we reproduce the bug? (as minimally and precisely as possible)

• Add ssh provider
• Create workspace with a fixed name, and point it to a folder (so files are uploaded)
• Run workspace (just so everything works)
• Uninstall devpod (and delete any data related to it)
• Reinstall devpod
• Go through steps 1 & 2, and you'll see in the logs that it sees a project with the same name and deletes it

Local Environment:

• DevPod Version: 0.6.4
• Operating System: linux
• ARCH of the OS: AMD64

DevPod Provider:

• Local/remote provider: docker | ssh

Anything else we need to know?
This might need to be another issue, but when you create a workspace using ssh, devpod sometimes fail to create a workspace due to permission issues.

[bkneis]

Thanks for raising your issue @ADRFranklin. Devpod persists the workspaces in your local folder ~/.devpod. When you uninstall devpod and delete the data, there is no way for it to know about any existing workspaces on any target. When you say So if the client happens to need to reinstall (due to system failure or similar issues) I'm not quite sure I follow why you need to do this? If you uninstall devpod all data will be lost. If you have a workspace failure, I would instead recommend simply running devpod up {name} to restart the devcontainer. There shouldn't ever be a need to re install devpod. Let me know if that helps!

[ADRFranklin]

When you say So if the client happens to need to reinstall (due to system failure or similar issues) I'm not quite sure I follow why you need to do this?

Recently I had a system failure and was unable to fully recover (lost all local files). I made the assumption that my data would be okay since it was on a remote machine, however I almost lost the changes (I ssh'ed in to the remote machine and backed up the .devpod folder), because I was not aware that reinstalling and re-creating the workspace would in fact delete my remote data (though backing up the folder was just something I did just in case). Devpod didn't warn me the data would be deleted and just went ahead and deleted it, if anything a confirmation should be given or some other way to handle that with user input.

There shouldn't ever be a need to re install devpod.

I would say that for most applications, however sometimes you are forced to, because of weird linux things. Sometimes it is unavoidable.

Would it not make sense to store some data on the remote to help with recreating the workspace? As if anything goes wrong on the client, it is then expected that all data is lost from that point on, which seems dangerous. I just think more measures should be in place to safe guard the data.

One question I do have is, is there a way to manually re-create the workspace locally in a way were devpod skips uploading folder data, and that and treats the workspace as if it's already been initialised? I would prefer this method for now, since there isn't currently a way to continue a workspace.

[bkneis]

Hi @ADRFranklin thanks for providing more info on your use case. I agree that we should make it clearer when recreating the workspace that data could be lost. Your solution of backing up the remote ~/.devpod sounds a good way to backing up changes. Unfortunately if you uninstall devpod and your local .devpod directory, devpod cannot determine if the workspace running on the remote. If you uninstall devpod and keep .devpod however, this should be possible.

I'll keep this issue open and if you have any specific ideas on how / what changes would need to be made to persistence of the remote .devpod then I'll be happy to review. But I think at the moment this is a lower priority as it occurs after a reinstall of devpod. Otherwise I think we should just improve the logs and docs to make what is happening clearer.