Hi,
I’m a bit confused here. I was doing some cleanup, and performed few deletes on device A, and also deleted a .stversions folder on device A.
On 2 other devices that share this folder, I’m getting the following:
[IDIDIDID] 21:25:23 INFO: Puller (folder "Shared Data", dir "STVERS~1"): delete: remove \\?\D:\<PATH>\Shared Data\STVERS~1: The directory is not empty.
[IDIDIDID] 21:25:23 INFO: Puller (folder "Shared Data", dir "STVERS~1"): delete: remove \\?\D:\<PATH>\Shared Data\STVERS~1: The directory is not empty.
...
[IDIDIDID] 21:25:23 INFO: Puller (folder "Shared Data", dir "STVERS~1"): delete: remove \\?\D:\<PATH>\Shared Data\STVERS~1: The directory is not empty.
[IDIDIDID] 21:25:23 INFO: Puller (folder "Shared Data", dir "STVERS~1"): delete: remove \\?\D:\<PATH>\Shared Data\STVERS~1: The directory is not empty.
[IDIDIDID] 21:25:23 INFO: Folder "Shared Data" isn't making progress. Pausing puller for 1m0s.
Device A reports “problematic” devices as “Syncing 80%, 0B”
The “problematic” path is DOS path to .stversions folder.
Is it in any way expected? Any workaround?
(ST v.0.14.33, Win10x64)
Indeed i do: SyncTrayzor v.1.1.16. It is bundled with FS watchers, i don’t know about it’s version though, whatever is in SyncTrayzor’s last version, @canton7 would know better…
The weird thing is that I never had any similar issues of DOS 8.3 paths popping up.
Any way to “refresh” it without nuking the index? It survives restarts…
Probably best bet is to back up, shut down all nodes, reset all indexes and take it from there.
The funky path is already in the index looking like it’s not a dup, but being a dup, so evaluating all possible behaviours is a bit hard.
In attempt to avoid index rebuilt (rebuilding full index would mean rehashing about 4TB of data on each device…) I tried to remove manually .stversions from impacted folder on all devices and archiving it elsewhere.