If .files directory in place, kody will throw error

[jh3y]

Issue summary

If you set up a new machine using kody. Unless the .files task is set first(?) an error will be thrown about not being able to unlink the current existing directory.

Expected behavior

No errors are thrown and the symlink for the directory is set

Actual behavior

Error thrown because an existing directory is in place.

Current work-around

Manually rm -rf the directory within the $HOME directory before running the Dotfiles task.

Steps to reproduce

Try setting up a fresh machine using kody.

[prayashm]

Can I work on this?

[jh3y]

Yeah sure 😄 I think the issue is around the fact that a symlink/directory is already in place when the symlinking task is executed.

I'm not 100% sure on how to replicate. This would probably be the first step in really nailing down what the issue is. I think the issue needs a slight rework to the core functionality of the symlink task in order to replicate/test. I think that it's probably ideal to be able to set where the symlinks are being set within the .kodyrc file. This way it's easier to test without having to tamper with the $HOME directory too much and will also make it easier to truly identify what the issue is.

@jh3y

[prayashm]

I tried replicating this problem.
Got 'EISDIR' error when there's a already existing directory e.g. .foo/ in $HOME and we are trying to create a symlink for something like: foo.link/ or foo.link
We can give prompt the user with [y/N] asking whether to delete the existing target directory with rm -rf.

Are you suggesting that we'll add target path of such occurrences to .kodyrc file so that users can report the error here with that as the log file?

[jh3y]

Hey @prayashm

EISDIR sounds familiar. Yeah, a prompt could work. However, I think it's always going to be a case of unlink or removal if a user is running this task. This kinda ties in with the issue around backing up current dotfiles #1.

I think by default the task should overwrite without prompt but ask the user if they wish to backup all current dotfiles to a location of their choosing.

My thoughts with the target path is so that it is easier to test the issue.

By default, all dotfiles are going to be within $HOME but if we prompted for this with $HOME being the default and the symlinking task having a target path as a parameter then this makes it easier to test in isolated test conditions; For example, a dummy folder where we want to put .gitconfig etc.

@jh3y

[prayashm]

So a to-do for this issue would be:

• Check if target path already exists as a directory at $HOME/.file
• If it does, overwrite it
• Store a list of target symlinks in .kodyrc

Should the last one be done only for scenarios where such problem occurs or always?

[jh3y]

Hey @prayashm

Yep, I think that's correct apart from the last one. Also I'd have it so $HOME is potentially configurable via prompt (for testing).

"So, where do you want your symlinks created? ($HOME)"

Instead of storing a list of target symlinks, prompt the user as to whether they wish to backup their existing symlinks or dotfiles.

"Do you wish to back up your current dotfiles? (Y/n) NOTE: current dotfiles will remain with additional .bak suffix"

Then instead of removing them, before creating the new symlink, rename the old one with a .bak suffix. This way if a user wants to reinstate their old symlink, all they need do is delete the one created with kody and remove the .bak suffix from their old dotfile. This is a technique I've seen used for backups elsewhere and seems to be the simplest option.

.gitconfig => .gitconfig.bak

This last part resolves #1 at the same time.

Hopefully that makes some sense 😄 If not feel free to fire away!

@jh3y