I’ve enabled Staggered File Versioning a few days ago. Today, I needed to restore a version but, when I clicked in Versions, it showed “No Data.” When I browsed the folder though, all file and versions are there.
How to fix this?
You have to enable file versioning on both computers. Then if you/Syncthing delete/change a file on computer A it will show up in .stversions folder on computer B
So on the device where you get no data, the .stversions folder contains files?
Yes. My versions folder contains:
Nov 18 09:31 B_Import~20181121-220123.csv
Nov 21 22:24 B_Import~20181122-225824.csv
Nov 19 09:06 CategoryMapping~20181120-215149.xlsx
Nov 21 23:01 CategoryMapping~20181122-233217.xlsx
Nov 22 23:41 MoneyFile Base.bank7
Nov 21 21:59 ~$CategoryMapping~20181121-230209.xlsx
Nov 22 22:44 ~$CategoryMapping~20181122-233639.xlsx
Nov 20 11:15 ~20181120-214956.DS_Store
Nov 21 22:26 ~20181122-223321.DS_Store
But Syncthing shows:
I was only interested in getting version on one computer…
You have a date filter set
The default one:
2018/11/23 23:25:43 - 1970/01/01 01:00:00just to be sure: you can only use the restore feature on the computer that has the files in the .stversions folder
Which seems wrong as the dates look backwards.
Sure. I have a different folder, but I’m restoring from the computer where I set the versioning, hence able to click the button “versions”
I’d check what it sends as part of the rest request, as I suspect the dates being backwards is the cause. I have no idea why it does that.
Ok, now in English 
I tried to recreate this:
A folder is set with versioning but since no deletes have happened the .stversions folder does not exist. If I click on “Versions” I see “no data” and “2018/11/25 15:45:30 - 1970/01/01 01:00:00” as date range, so this seems to be correct and expected.
For testing I copied a .stversions folder from another syncthing folder. If I then click “Versions” I see normal restore modal with possibility to select date & files.
My guess is in @wearybasalt case that Syncthing cannot read the .stversions folder.
This is what have in my versioning folder:
pi@soul:/media/iomega $ ls -la
total 80
drwxr-xr-x 8 pi pi 4096 Nov 20 22:16 .
drwxr-xr-x 4 root root 4096 Nov 20 10:45 ..
[...]
drwxr-xr-x 3 pi pi 4096 Nov 25 14:29 versioning
Let’s look at core.sql file inside versioning:
pi@soul:/media/iomega/versioning $ ls -la
[...]
-rw-r--r-- 1 pi pi 24592384 Nov 24 22:41 core~20181124-224401.sql
-rw-r--r-- 1 pi pi 24965120 Nov 25 13:12 core~20181125-132751.sql
-rw-r--r-- 1 pi pi 24965120 Nov 25 13:34 core~20181125-143725.sql
So it can write. I followed the instructions setting up the service on my raspi and AFAIK I’m using the pi user
pi@soul:/media/iomega $ sudo systemctl status syncthing@pi.service
● syncthing@pi.service - Syncthing - Open Source Continuous File Synchronization for pi
Loaded: loaded (/lib/systemd/system/syncthing@.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2018-11-22 19:11:26 CET; 2 days ago
Docs: man:syncthing(1)
Main PID: 23312 (syncthing)
CGroup: /system.slice/system-syncthing.slice/syncthing@pi.service
└─23312 /usr/bin/syncthing -no-browser -no-restart -logflags=0versioning? I suspect some shenanigans here with a non-default version location.
I just use the option to choose my own path. Does that break things? Is this the reason it doesn’t work?
Maybe?
I reverted to the default location and now it shows up correctly. I’ve manually reverted to the version I wanted, so all is good.
Could then be something wrong with option which allows selecting a different place to store the versions?
We should kill the option allowing to specify that.
Nonetheless, would you mind filing an issue on it @wearybasalt? The functionality is there whether we like it or not so it should ideally work, too.