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

Extracting and hardlinking downloads? #80

Open
poperigby opened this issue Dec 9, 2024 · 5 comments
Open

Extracting and hardlinking downloads? #80

poperigby opened this issue Dec 9, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@poperigby
Copy link
Contributor

This might be a horrible idea, but what do you think about having files in the downloads directory being extracted, and then hardlinked to the mod directories? This would alleviate the need to re-extract when you want to reinstall (which can be slow), and would save space by not having files be duplicated in both the downloads and mod directories. The only issue I could think of would be how to handle a user editing one of the files, because it would also be modifying the one stored in the downloads directory, but that might be a deal breaker.

@limo-app
Copy link
Owner

Seems worth implementing for users who often reinstall mods, especially FOMOD ones.

To avoid confusion, i will make this an optional feature that is disabled by default. Otherwise this would lead to some confusion when somebody tries to reinstall a mod and file modifications are not reverted.

@limo-app limo-app added the enhancement New feature or request label Dec 14, 2024
@poperigby
Copy link
Contributor Author

Making it optional might be a good idea. I think brainstorming some ideas for how to handle the issue of downloaded mods being modified from the mods directory would be a good idea though, because it would make this more useful.

@limo-app
Copy link
Owner

Not all modifications would cause issues with the current implementation. If you edit a file using xEdit, the plugin file is recreated instead of overwritten. This breaks the link, forcing Limo to recreate it. Afterwards the file in the download directory would no longer be a hard link of the files in the mod and target directories, which circumvents the issue. Otherwise i don't know of a way to protect the files in the download directly when the file in the target directory is modified. At least not one that would work for all filesystems. The copy on write functionality of BTRFS would solve this, but would obviously only work if you are using a filesystem that supports CoW.

@poperigby
Copy link
Contributor Author

Maybe there could be an option to use CoW for people who do use those filesystems? I do. I guess you could also monitor the downloads directory?

@limo-app
Copy link
Owner

Maybe there could be an option to use CoW for people who do use those filesystems? I do

There are some other advantages to this as well. CoW for deployment would allow detecting and, if desired, reversing any modifications to deployed files, not just those that delete the link. Will look into this.

I guess you could also monitor the downloads directory?

This would only allow detection of file modifications. The only way to undo them would be to keep the original archive, which would require extra disk space.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants