Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Attempting to symlink into a non-existing shared directory causes unintended conflicts #31

Open
Jasha10 opened this issue Aug 21, 2024 · 4 comments
Labels
invalid This doesn't seem right
Milestone

Comments

@Jasha10
Copy link

Jasha10 commented Aug 21, 2024

At the head commit ee3c2bd I'm getting a compilation error on windows:

> cargo check                                          141 08/21/2024 01:28:34 PM
    Checking tuckr v0.9.1 (C:\Users\Jasha\dev\Tuckr)
error[E0382]: borrow of moved value: `f`
  --> src\symlinks.rs:44:33
   |
22 | fn symlink_file(f: PathBuf) {
   |                 - move occurs because `f` has type `PathBuf`, which does not implement the `Copy` trait
23 |     let src_path = f;
   |                    - value moved here
...
44 |                 let result = if f.is_dir() {
   |                                 ^^^^^^^^^^ value borrowed here after move
   |
   = note: borrow occurs due to deref coercion to `Path`
help: consider cloning the value if the performance cost is acceptable
   |
23 |     let src_path = f.clone();
   |                     ++++++++

For more information about this error, try `rustc --explain E0382`.
error: could not compile `tuckr` (bin "tuckr") due to 1 previous error
@RaphGL
Copy link
Owner

RaphGL commented Aug 21, 2024

oof, guess I'll have to install windows to make sure things are working again as intended. Thanks for the heads up

@RaphGL RaphGL added the bug Something isn't working label Aug 21, 2024
@RaphGL
Copy link
Owner

RaphGL commented Aug 22, 2024

So today I went to develop tuckr on windows and try to spot where things are going wrong. I've fixed this error and some others causing tuckr to not function as intended on windows.

Right now tuckr is usable on windows and works as intended. but I'm getting some false positive conflicts (they don't actually show up when you run tuckr status <group>). So I'll have to dive in and see why that's happening, so I won't close this issue just yet.

@RaphGL RaphGL changed the title Compile error on windows Windows version resulting in false positive conflicts Aug 22, 2024
@RaphGL RaphGL added invalid This doesn't seem right and removed bug Something isn't working labels Aug 22, 2024
@RaphGL
Copy link
Owner

RaphGL commented Aug 26, 2024

After debugging for a little bit I found out that the reason why conflicts happen on windows is because I'm attempting to symlink a bunch of dotfiles within a .config directory without it already existing on windows and tuckr does not create directories that are shared amongst different dotfile groups.

so this fixed it for me:

mkdir .config

I'll be looking into converting shared directories from symlinks to standalone directories to fix this issue.

@RaphGL RaphGL changed the title Windows version resulting in false positive conflicts Attempting to symlink into a non-existing shared directory causes unintended conflicts Aug 26, 2024
@RaphGL
Copy link
Owner

RaphGL commented Sep 18, 2024

I've been thinking about this issue and the most performant way to do this without introducing a horrible O(n^2) type performance penalty by comparing every single path in the validation cache seems to be to outright change the data structure/approach used.

I'll be conducting a big(???) change of the validation portion of the program where instead of using a HashMap for the caching/validating the dotfiles, I'll instead create a tree data structure that mimics the file system's, where each node is something akin to this:

struct TreeNode {
  path: Dotfile,
   shared: bool,
  nodes: Vec<Box<TreeNode>>,
}

So instead of separating everything by group all dotfiles are stored in a single source of truth "file system".
The program will detect when a parent is shared by more than one dotfile group by doing something like this:

if parent.any(|child| child.path.group != parent.path.group) {
  parent.shared = true;
}

If the node is shared, it means it should be created instead of being a symlinked directory.


So far I haven't found a tree data structure that fits what I wanna do so potentially I'll be writing my own data structure for this. If I can I'll try to make it cache friendly by allocating everything contiguously.

Also since this requires quite a bit of changes to make the symlinking process more accurate, I'll refrain from shipping this into the following 0.10.0 release and push it to the next release.

@RaphGL RaphGL added this to the 0.11.0 milestone Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

2 participants