andrew_

Followup: I've been messing around inside the above referenced share on one of the two endpoints. I've been busy removing old files, renaming and creating new folders, and moving files from previously existing folders into other/new folders within the hierarchy of that share. One large move of files to a different subfolder sparked a 1.1GB re-transfer of data (how incredibly inefficient). Another folder create, followed by file move from a preexisting subfolder into the newly created folder triggered an apparent re-transfer of that file (6.5 MB), at the conclusion of which the share's sync successfully completed with a datestamp. In short, it's no longer stuck, and the situation fixed itself somehow. The other share (stalled w/7.5 kB outstanding), has been that way for months, despite lots of file/folder manipulation similar to the above, and remains in that state. One would need some visibility into the internal state of the client. For instance, what exactly is the client trying to arrange the transfer of when it's showing (D: 7.5 kB)? And so... The inefficient re-transfer of files which were simply getting moved between subfolders of a share sparked me to start this topic.

I have a share under which I just moved 1.1GB of files out of one subfolder, and into a different subfolder as part of a reclassification of those files. The result of this action was for BTSync to delete these files from the source subfolder on the remote endpoint, then re-transfer them from the local endpoint into their new destination subfolder on the remote endpoint. 1.1GB of data was caused to flow across the network, that didn't strictly need to occur. Tracking moves of files between subfolders, and folder creates/renames/deletes, is something Microsoft's SyncToy can do, so that minimum data is copied. This seems to be an area to target for refinement in BTSync. It would save a lot of bulk transfer utilization where files may be moved intact between folders in a common hierarchy. v 1.2.82 in use

I notice precisely the same symptom. I have a setup with 11 shares on two endpoint systems. Two of them are "stalled" in this manner, always with a tiny amount (up to just a few tens of kB) left to transfer. The first affected share developed this issue several months ago. The amount remaining on stall is always the same, 7.5 kB, and the perspective (upload/download) is different and appropriate depending on which endpoint you're looking at. The share is bidirectional, with lots of content changing on either side. Sync appears to work correctly, however, despite the reported amount remaining to transfer; I'm not noticing any difference between the two folders once it settles, at this point. The other share with this issue just developed it right now as I write. It was also a bidirectional share, with a past static state for several months (no contents changing), and just earlier today with new content on either side (so the result after sync was a merge). It's done its first sync since the content changes, and it's stuck with 31 kB left, yet the sync appears to be complete when examining the corresponding folder on each endpoint. I've not tried removing/recreating the share on BOTH endpoints. But I have tried removing/recreating one of the shares on just one endpoint: after reindexing and without apparently transferring any data, that endpoint settled stuck at the same apparent point, D: 7.5 kB in that case, as it had been before I tried the remove/recreate operation. The endpoints have been upgraded progressively since this past summer, and are presently running 1.2.82. Both shares with the issue were established under older versions of the software, but only now has the symptom presented with the second share as just detailed. The sync clients are run irregularly on both endpoints, one endpoint is a laptop with an irregular connection to the LAN, and periods exist where much change can happen with the contents of the folders forming the shares between runs of the client. I solicit followup/brainstorm reports from any interested forum participants. Yet to consider: What would happen if I copied the secret joined a 3rd node to one of these stuck shares? Would it also get stuck at the same level left to transfer, and in which direction from/to which of the other nodes? What if I removed the shares from both nodes (or all three in item 1 above, if the 3rd node also exhibited the symptom), and recreated the share across all? Are the affected shared folders on each of the endpoints truly in sync? It appears so, but only based on a cursory inspection of file count, file name, file size. Is there a small content descrepancy somewhere? I've not looked at the housekeeping folder .sync-trash. Could the difference be down to filesystem metadata? One endpoint is WinXP, the other is Vista. Perhaps a subtle permissions issue is standing in the way.Cheers.