Files remain in `.stversions` past max age

Support
1

So I googled it and found a recent similar complaint on Reddit: https://www.reddit.com/r/Syncthing/comments/w0ctkx/files_remain_in_stversions_past_max_age/ but of course on reddit the details are a little lacking.

Only one of my systems seems to be experiencing the problem, it’s running v1.19.0, Linux (32-bit Intel/AMD) and yes, I’ll probably be upgrading to the current release a little later…

I have two directories ‘sharing’ the same .stversions directory but using different versioning parameters. Could this be the source of my problem? My other systems seem [I think, can’t see all 7 right now] to be using the same versioning parameters on the two folders.

Dir1:
        <versioning type="staggered">
            <param key="cleanInterval" val="3600"></param>
            <param key="maxAge" val="604800"></param>
            <cleanupIntervalS>90000</cleanupIntervalS>
            <fsPath>/home/myhome/.stversions</fsPath>
            <fsType>basic</fsType>
        </versioning>
Dir2:
        <versioning type="simple">
            <param key="cleanoutDays" val="6"></param>
            <param key="keep" val="2"></param>
            <cleanupIntervalS>9000</cleanupIntervalS>
            <fsPath>/home/myhome/.stversions</fsPath>
            <fsType>basic</fsType>
        </versioning>

The versioning configuration is setup separately on each folder, so my leap to conclusion was that they didn’t need to be the same. Or is there a limited compatibility issue caused by my using a common .stversion directory?

regards,

/dave

2

Firstly, just a comment, but Simple File Versioning is bugged regarding old versions cleanup (see https://github.com/syncthing/syncthing/issues/7988). I’d strongly advise not to use it until this issue is fixed.

I’ve just done some testing though, and I cannot reproduce the behaviour mentioned here. In my case, the versions are cleaned up as expected, also when using a custom versions folder. You may want to inspect the logs, perhaps with versioner debug logging enabled. I’d suggest to set the Cleanup Interval to something very low just for testing (e.g. 30 seconds), so that you don’t have to wait for it to trigger.

Please do upgrade to the newest release before doing any testing, as no-one is probably going to debug the old one.

3

In any case, the different versioners have different mechanisms both for deciding when to clean out files and how those files are tagged with the date they were archived. Having multiple different versioners pointing to the same versioner directory is not necessarily a great idea.

4

Hmm. Sounds like the result of code-creep during the effort of adding requested enhancements. Sigh. Noted, although I’ll probably continue the practice as I have other methods of retrieving archived or ‘lost’ files.

p.s. Thanx for your efforts. It’s a great product. Although I sometimes worry about the said code-creep during enhancement.

5

Status update: As part of my normal daily routines, I fully stop and restart syncthing. And these restarts weren’t fixing it. I did go into the Web GUI and tweak some of the parameters. Thus updating config.xml and restarting the process. And suddenly it fixed itself, deleting the older files.

So something was wedged someplace. What? Who knows.

It’s running fine. Still on the older v1.19.0.

As an aside: I have 5 systems running on v1.19.1, c1.20.1 and v1.20.3 all with 2 synced folders containing a total of 1,406 files in 52 folders and ~571 MiB. It works perfectly for my needs.

Thanks.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.