ChrisH

Oh, and please see this thread: http://forum.bittorrent.com/topic/19668-help-newer-files-overwritten-by-older-files/ concerning the same problem.

Then your design is flawed. An upgrade (regardless of how big the changes are) should never lead to data loss. I (kinda) get the decision to use the simplest conflict resolution method there is - last added wins -, but that only works for changed files after the first initial sync has been done. For all other cases the user should be asked what to do (e.g. when adding a new folder with an existing secret there should be a option to decide whether to replace local or remote files on conflict), and like I said, a "simple" (for the user) update should not change the status quo.

Sorry, didn't think to activate debug logging and the normal sync.log shows nothing. Should be fairly easy to repro, though - in my case it happened on every single device that was updated to 1.1.27.

The problem seems to be that during reindexing (which has been started by every one of the last updates) all local files are always regarded as newer than existing files on the sync peers. Even if the updated client has been offline for four weeks. Which is really annoying.

The main wishlist thread has become somewhat cluttered because all issues (protocol, features, UI, bugs) are mixed together. I would like to clear that up a little by starting a separate thread for all UI improvements, i.e. all things that can be made better without adding core features or changing the core behaviour of sync. Since I only use the Windows GUI, I cannot speak for Mac / web GUIs, but from what I could see on screenshots they should be pretty similar. Feel free to add your ideas or comment mine here. My wishes: show the folder (number or short name) in both the "transfer" and "history" tabs add a separate "queue" tab showing all yet unsynced files as a treeview per folder and device with options to skip / ignore single files (or maybe integrate it with the "transfers" tab?) show conflicts / overwritten / deleted files in a separate tab with options to restore the overwritten version show an ETA and/or overall sync progress show a drill-down report at the "finished syncing with <DEVICE>" event so the user can easily determine what exactly was changed without having to scroll through the history tab add an option to skip / defer a running file transfer from the "transfer" tab so more "important" files can be synced first separate the GUI from the worker daemon so BTSync can run as a native Windows service (or use the existing web GUI also for Windows - whatever works)

That's what IMAP and Exchange are for.

I did exactly this (robocopy the whole folder, then install BTSync) on several machines without any problems. But that was before I even knew about .SyncID files - now I would delete it too.

No problem. But then I'm out of ideas - does not seem to be a Windows problem after all.

And is there a user "pi" on the Windows system? (I have no experience with Home Server, I can only speak for "normal" Windows versions)

- what permissions are set on the share in Windows? - what permissions are set on the files in Windows? - with which user account do you connect to the share?

I'd guess it will not sync while Outlook is running.

I think there is no elegant solution for using container-based encryption tools together with file-based sync tools. On Windows I'd use something like http://sourceforge.n...ojects/axcrypt/ - maybe there is a similar cross-plattform tool you can use?

Is this WiFi? What speed do you get using other means of transfer?

Same on my wife's Motorola Pro+. However it had an option to scale the app's interface so the QR button can be (barely) made visible.

Regarding broadband? Yes, we are. Everybody has to have something

Not yet, but this functionality has already been suggested several times.

That's the default in Germany.

You can just start the scheduled task manually from the MMC - no reboot required.

How the hell should a hibernated system know when some other node goes online? You will have to wake it up yourself.

Why? You could still sync encrypted files separately, not one single huge blob. Edit: Yes, if you used a container-like external encryption (which I wouldn't want), you would have a huge blob. But changing a single file in the container shouldn't change the whole container, only the chunks where the file sits.

Huh? BTSync *already does* encryption, so they already reinvented the wheel (if you want to call it that). All they have to do is skip the decryption at selected nodes after receiving the file. Nobody is talking about disk encryption. Also, 7zip or Truecrypt didn't "invent" anything.

For files to sync it doesn't, but how about "internal" files? (I only have Windows boxes, I can't test it) I was hoping that would be cached, but you could be right. It was just a wild idea.

Yes, but it's solvable. Here's my suggestion (including the read-encrypted-only wish from the wishlist thread): Have four secrets per folder. 1) Master: Can approve new devices, and read and write cleartext. Device approval list is signed and distributed with the folder content. 2) Read/Write (as it is now): Can read and write cleartext, but only devices on the approval list can connect. 3) Read only (as it is now): Can read cleartext, and only devices on the approval list can connect. 4) Store only: Can only read data in its encrypted form, and only the hashes or similar, not the original filenames. Each device should also have a unique key, guessing an approved device name must obviously not be enough.

So he just enters the secret (which he knows) on another machine, or renames his device. Then what?

Can you symlink the .syncid to a RAM disk or something until this is fixed?