Data loss possible at nearly every step

[Walter-o]

For linux tuckr so far i found 0 video explanations and barely any mentions online.
So i figured i read the official github page for this project and then wing it a bit with --help and man page if needed.

However, this went wrong in insane ways.

I had times when it gave a cryptic rust error because it tried to resolve a broken symlink it made itself.

And now it zeroed out my nvim config from just running 2 benign commands.

From what i can gather tuckr does not expand nicely and instead overwrites files with emptiness, and i did the command this way to save time travelling through directories too.

I have to now pick up the scraps of the nvim explosion and am going to try out GNU stow for the first time, hopefully this isn't as brittle as tuckr is at the moment.

Also if i made any insane mistake in using tuckr i would really like to know. I am using the "-a" flag when deploying to evacuate conflicting files, this should never end in zeroed out files.

[RaphGL]

From what i can gather tuckr does not expand nicely and instead overwrites files with emptiness, and i did the command this way to save time travelling through directories too.

Tuckr will never attempt to override things unless you tell it to.
By default you should not use the -a and -f flags. These flags should only be used to handle conflicts once they occur and tuckr tells you to resolve it when using tuckr status.

I have to now pick up the scraps of the nvim explosion and am going to try out GNU stow for the first time, hopefully this isn't as brittle as tuckr is at the moment.

I suspect that the reason why this has happened is because of issue #31 (comment)

I suspect that you overwrote a symlink with another symlink when you did -a. If you do ls -l you likely will find a cyclic symlink, which corrupts your nvim dotfiles. This is a rare issue but it's sadly a problem for the time being. The "quick fix" for now is to just create the parent directory that is shared by your dotfiles and then add your dotfiles.

I'm working on fixing this issue atm, it should be shipping on the next major version (0.11.0) .
You can see the progress on resolving this issue here

---

For linux tuckr so far i found 0 video explanations and barely any mentions online.
So i figured i read the official github page for this project and then wing it a bit with --help and man page if needed.

I haven't gotten around to writing a man page or making any videos about it, as only recently people have started using this. I should definitely get around to it some time. For now the best docs are just the README and the Wiki page here on github.

I had times when it gave a cryptic rust error because it tried to resolve a broken symlink it made itself.

If you could share your stack traces/error messages with me so I could track down the crashes and either fix that issue or provide a better error message it would be great :)

[Walter-o]

Hey thanks for confirming there is a bug.

I am already halfway in cleaning up the explosion debris but when it just happened, i did see a symlink that linked to itself, so i think you are right in that i should not have used any of the "-a" or "-f" flags since it might be missing validation checks.

For the cryptic rust error, i just had a symlink inside my ~/.config/cmus/playlists that linked to a nonexistant file, which caused the error when trying to do tuckr push stable cmus.
Sadly i could not get the stacktrace, the error message was something like "file or directory not found" when i exported that debugging variable.

[RaphGL]

I am already halfway in cleaning up the explosion debris but when it just happened, i did see a symlink that linked to itself, so i think you are right in that i should not have used any of the "-a" or "-f" flags since it might be missing validation checks.

Afaik all the validation is working properly, the only thing missing is that tuckr itself doesn't create shared directories, so if you have 2 groups that need to symlink into X directory and X doesn't exist, then a race condition will occur, so the first group to symlink the directory ends up owning it. That's why creating the directory fixes the issue.

For the cryptic rust error, i just had a symlink inside my ~/.config/cmus/playlists that linked to a nonexistant file, which caused the error when trying to do tuckr push stable cmus.

I've fixed this issue. Tuckr now reports an error when you attempt to push an invalid file. Thanks!

[Walter-o]

so if you have 2 groups that need to symlink into X directory and X doesn't exist, then a race condition will occur,

I only have 1 group named Stable. if that helps in debugging.

Also i took a look at GNU stow today and realized it's a wooden vehicle compared to tuckr. 😳
So i will really look forward to the next release that addresses the bug.

In the meantime i replaced the symlink thing with rsync, at the moment it's 1-way traffic commits so i should be ok.