davew_uk

No need for NAT punching or multicast searching in a LAN-only scenario with fixed IP addresses. That is my scenario - and I'm not bothered about gb/month or traffic caps either, the point is if the app has nothing to do it should do NOTHING. If you are accurately tracking file system changes (via "instantaneous" callbacks or via regular timed scanning or a combination of both, I don't care) there's surely no need to generate any network traffic unless a file has actually changed? what can you possibly gain from sending 50-150kbs of data constantly? I look forward to seeing how this app grows and gets better in the future, but right now I'm not using it.

Was going to let this one go by but I've got my pedantic head on. In the old days when I was a wee young coder, ALPHA testing refers to testing programmers did on their own code while they were working on it. It would only be after alpha testing was complete that you could move to BETA testing where you'd open it up to other users. So if the likes of you and me are testing this app, then is in beta

My OS preference is to move files to the recycle bin. So I guess that's a bug. Because its a hidden folder, and users won't see it unless a) they have view hidden items enabled and they check it on a regular basis. The system recycle bin is way more intuitive for average folk and I don't know why it isn't the default (even if, as yet, it doesn't work).

In general there are two broad approaches to detecting changes. What you describe is brute-force polling where you have to go check the resource you want to see if it has changed on a regular schedule. The alternative is that the resource offers up an API where your app can register an interest in certain changes, and then go to sleep. Then the system will "call back" to your app and wake it up when the resource has changed in a way that you said you were interested in. On windows at least there are various file APIs that you can use to automatically monitor a folder for changes in the second, callback-like manner. If all apps had to wake up, traverse the file structure and check for changes and go back to sleep again on a regular schedule then your antivirus, backup software like Acronis etc. would be a nightmare hell of disk thrashing.

A pretty common situation came up last night - I edited a shared file on two computers last night while they were logged out of Sync. When I realised, and tried to sync up, instead of taking the newest version of the file, it took the oldest version and my changes were wiped out. What I found unusual is that there was *no* attempt to flag to me that there was a conflict - nothing in the history suggested that something had happened, its only when i reloaded the file did I realise I'd lost my changes. Now I'm worried because I've used Sync on several computers to sync up some large folders of files that had been previously kept up to date with Synctoy and there would inevitably be the odd conflict as we didn't run it every day. In the event of a conflict could you please ensure that the Sync app asks a human which version of the file they want to keep? Also, although I have "Delete Files to Sync Trash" *unchecked*, when a file deletion occurs on one computer the corresponding file on the other computers is not being moved to the desktop trash as the manual suggests that it should. I regard this as an essential feature and the app is pretty much unsafe without it.

That doesn't sound like a lot compared to what was observed on my computers. If it is working as designed, its using way too much bandwidth for an idle state. If it isn't working as designed, then fair do's we'll wait for the fix. FWIW on the first point, I believe that it is possible to design a protocol that doesn't require constantly polling the network. For example, you could cache peers and only broadcast "are you there" pings if they are found to be unreachable at their previous IP address when the app actually needs to contact them to send them a file. Files change very little, certainly not on a second-by-second basis! My expectation, as a user of this type of application, is that when it has nothing to do, it should sit quietly and do *nothing*.

OK - but I'd like to also pose a third question:- it seems to continue to use large amounts of bandwidth even when syncing is paused and no other peers are on the network. This is when only "Search LAN" is checked in the folder preferences, though the behaviour isn't significantly different with the default options.

Two questions:- 1. Why continually send data that hasn't changed? that's inefficient - you should only send the directory tree data when something has changed, and you should only send the part that has changed. 2. Why does it still multicast just as much data even when no other peers have been detected? Sorry guys, but anything that uses that much bandwidth constantly AT IDLE on my network isn't fit for purpose.

Right, but this is long-term idle performance - I've been monitoring it for several hours, no files are being changed. Do you think that the bandwidth usage as shown in the screenshot elsewhere in the thread is reasonable for idle usage? I think it should be as near to zero as humanly possible myself.

Here's a quick screencap of what I'm seeing in Performance Monitor:-

Thanks :-) Actually I went through all the options individually and in combination - with "use tracker server" enabled on its own, all traffic goes out over the internet to some AWS server. With "Search LAN" enabled on its own, all the traffic remains within the local network, seemingly using Multicast. Now I don't mind if it has to ping every few seconds - but it is averaging 50 Kbps and peaking over 100 Kbps. That is *way* too much for "are you still there?" messages

I've been using Bitorrent Sync v1.0.116 this afternoon and have already got most of my folders set up and syncing fine. I was a heavy Windows Live Mesh user till the service shut down, whereupon I've been limping along with just Synctoy. After setting things up and letting it do its thing I figured the network activity would pretty much die down to nothing once the syncs completed, but even several hours after finishing this was not the case. Instead, I'm seeing regular spikes of network activity up to 100 Kbps-ish between the various devices on the network I've just synced. The spikes seem to occur at roughly 8-10 second intervals. After fiddling with the folder preferences I have come to the conclusion that its down to peer discovery and it seems unusually "chatty" - I don't see why it should need to use quite so much bandwidth so regularly just to "ping" other peers, is there a way that this could be reduced? Kind regards Dave