dotfiles -r deletes permanently? about dotfiles HOT 6 CLOSED

First, I am deeply sorry if I've caused you to lose any configuration files. If I can sort out exactly how this happened, I will add tests to make sure this regression never happens again and perhaps a confirm dialog before anything is removed permanently so you know when a destructive operation is about to occur. There is a -d, --dry-run option that will cause dotfiles to only print the commands it would execute and not actually do anything. This might be helpful in the debugging process.

I executed your exact steps you've listed, and dotfiles executed correctly for me. Let me explain what I see:

• dotfiles -a .config: I assume .config is a directory, so the entire directory is moved into the repository (~/Dotfiles by default) and a symlink at ~/.config is created and points to the directory that now lives in the repository. So ~/.config -> ~/Dotfiles/config.
• dotfiles -sf: This does a force sync, which will create any missing symlinks. The --force option will cause any existing files that should be symlinks to be removed first. This is a destructive operation and I'll consider adding a confirmation dialog there. But the commands you've listed above should not have any effect on ~/.config as it's already a symlink that points to the correct place.
• dotfiles -r .config: This does two things:
  • Removes the symlink in your home directory (~/.config in this case)
  • Move the config directory out of the repository and back to its original location. So the result is that ~/.config is once again a directory and no longer a symlink. Essentially we're back to where we started.

So it's possible that the files are still there, but not in the location you're expecting. Without access to the machine, it's impossible to know for sure. But I'm more than happy to work through this with you. I do make mistakes and this could be a terrible bug -- and for that I apologize. If you can help me to understand your exact steps and what the result was, I will fix those bugs immediately.

from dotfiles.

Thanks for the information and your participation. I did the exact same commands as listed above, but I had "config" and "vim".defined as packages. Issueing the 3 commands above with 0.6.2 installed from pip made my system unbootable because .config/awesome (my window manager) was a symlink to the repository where the configuration was deleted. Restoring the original files with -r did not work for the packages.. I tried extundelete but it failed to recover..

from dotfiles.

Ahh I see now. Yes, this is a bug. The exact problem is this: the command line add operation -a, --add does not know about packages, so it adds the directory as it normally would - as a toplevel symlink. But the -s, --sync operation is aware of the package configuration and says "the contents of this package are not the symlinks that I expect" -> and the -f, --force option clobbers them into oblivion.

Your machine is still very much bootable, you'll just have to ctrl-alt-f1 and login to the console to fix things up.

I fucked up good, and I'm really sorry this happened. If you're ever in the mid-atlantic region of the US, let me know and I'll buy you a beer.

Moving forward, I'm going to do two things:

1. Add package support to the add operation so you cannot get into this state where sync doesn't know what's going on.
2. Default to user-confirmation for all destructive (remove) operations - there aren't many, i think only force will do such a thing. I'll add a -n, --no-confirm for users to opt out of this.

I'll get to work on this as soon as I get home. But again, I'm really sorry. Thanks for helping me with the information I need to get this fixed up.

from dotfiles.

No worries. I reconfigured everything today and I like it even better than it was before and learned a lot about my window manager. So it was not for nothing. I removed the package definition and added the whole .config subfolder with the -a option. This seems to work. I still might get back to your offer at some point =)

from dotfiles.

Ok, I just uploaded 0.6.3 which prevents the add operation from doing the wrong thing. It's a step in the right direction, but certainly not complete. I will leave this issue open along with #20 until everything is in good shape.

Packages should work fine as long as you add them manually, and the CLI should support this soon. My .config directory is pretty crazy right now so I suspect you'll want to revisit this feature at some point.

Thanks again for all the input, and happy new year!

from dotfiles.

I'm nearly done with the next major version and I decided to remove the force option completely. The reasoning is that if a conflict arises such that some data must be removed - that is best left to the user. So dotfiles status will indicate conflicting dotfiles and user must resolve them in whatever way is appropriate.

New version will hopefully be released in a week or so.

Cheers

from dotfiles.