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

lib/versioner: Clean the versions dir of symlinks, not the full folder #4289

Closed
wants to merge 8 commits into from
Closed

Conversation

calmh
Copy link
Member

@calmh calmh commented Aug 8, 2017

Prevents the damage, while not recovering from it.

@AudriusButkevicius
Copy link
Member

Why can't we do a one-off cleanup as part of config migrations? If someone sets up a symlink explicitly perhaps we should not nuke it?

@AudriusButkevicius
Copy link
Member

Regarding recovery, we could check time of

@AudriusButkevicius
Copy link
Member

Sry, pocket actions.

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

This thing should be removed in the long run anyway. I'm not super keen on trusting this to a migration; there might be folders that are offline or whatnot.

@AudriusButkevicius
Copy link
Member

Offline?
So when are we removing this?

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

So what we could do for recovery is list our "have" index, then look for any other older entries in the index for deleted symlinks where the delete is recent. I'm not super hopeful that many places will have those entries intact but it's worth a try I guess.

"Offline" as is on a removable disk for example.

I'd remove this when we have a small-digit number of <0.14.34 clients out there.

@AudriusButkevicius
Copy link
Member

In my phone so can't check, but I don't think we can classify deletion as recent as we don't update the mtime?

@AudriusButkevicius
Copy link
Member

If we knew they are recent, we could check mtime of syncthing.old binary or time when release hit the shelves as the cutoff period, and time when the release was pulled as the other cutoff

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

We set the mtime to the delete time. I'm just less hopeful that we find an old index entry. But I'm hacking it currently.

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

OK, here's another attempt that's cleaner. It does the cleanup in a migration after all. Later, as part of the same migration, it attempts a recovery sweep.

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

@st-review merge

@st-review
Copy link

👌 Merged as fa5c890. Thanks, @calmh!

@st-review st-review closed this Aug 8, 2017
st-review pushed a commit that referenced this pull request Aug 8, 2017

// Try to find an older index entry.
for deviceID := range m.cfg.Devices() {
olderFI, ok := fs.Get(deviceID, fi.Name)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we unset target on delete?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

@AudriusButkevicius I merged it because I need to drop something within the hour, but since you're here I'll give you a few minutes to find serious problems with this as well.

Not minor nits though, at this point.

@AudriusButkevicius
Copy link
Member

Lgtm

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

Oh. We also don't actually set the modified time like I though we do, so the recovery step is broken.

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

I don't think there's anything reliable we can do do undo that then unfortunately

@AudriusButkevicius
Copy link
Member

Fine, drop the extra code in that case, and make an enhancement for the future?

@calmh
Copy link
Member Author

calmh commented Aug 8, 2017

Yes

viable-hartman pushed a commit to viable-hartman/syncthing that referenced this pull request Aug 25, 2017
@st-review st-review added the pr-merged Legacy label used in the past for pull requests merged to the main tree label Jan 15, 2018
@st-review st-review added the frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion label Aug 9, 2018
@syncthing syncthing locked and limited conversation to collaborators Aug 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion pr-merged Legacy label used in the past for pull requests merged to the main tree
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants