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

Add ability to configure number of days until .unison*tmp files are deleted #837

Closed
LubosKolouch opened this issue Nov 19, 2022 · 2 comments
Labels
effort-medium issue is likely resolvable with <= 20h of effort enhancement issue is a request for a feature, and not a defect impact-low low importance wontfix maintainers choose not to work on this, but PR would still be considered

Comments

@LubosKolouch
Copy link

Hello,

Currently unison most likely deletes the old .unision*tmp files after 30 days.

It would be nice to be able to configure it either in number of days, or in number of runs.

For example - when running next time, just delete the tmp files that were created when the sync did not complete before.

Thanks...

@gdt gdt changed the title Configurable .unison*tmp files deletion days Add ability to configure number of days until .unison*tmp files are deleted Nov 19, 2022
@gdt gdt added enhancement issue is a request for a feature, and not a defect wontfix maintainers choose not to work on this, but PR would still be considered impact-low low importance effort-medium issue is likely resolvable with <= 20h of effort labels Nov 19, 2022
@gdt
Copy link
Collaborator

gdt commented Nov 19, 2022

Seems valid but I cannot see myself ever getting to it :-) I encourage you to read the code and try an implementation and test it. PR (with doc change) welcome.

@gdt
Copy link
Collaborator

gdt commented Mar 22, 2023

@gdt gdt closed this as completed Mar 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort-medium issue is likely resolvable with <= 20h of effort enhancement issue is a request for a feature, and not a defect impact-low low importance wontfix maintainers choose not to work on this, but PR would still be considered
Projects
None yet
Development

No branches or pull requests

2 participants