Chris V

Uninstalling looks simpler than reverting to 1.4! This folder was never shared read-only, but I can't be sure whether it was first shared from the Windows machine to the Linux machine or vice versa (ie which machine the key was actually generated on). Is there anything you would like me to check for you before I uninstall & re-install?

Same here – I've not been able to use Sync at all since upgrading to 2.0. I was syncing between a Linux (Mint) computer and a Windows (7) computer. On the Linux machine, I can see 4 peers; hovering over them shows "Read & Write • Classic folder". However, when I select 'Share...' the 'Read & Write' option is greyed out, and hovering shows "You don't have Read & Write access to this folder" (which I certainly do). I have previously (v1.4) been sharing it 'Read & Write', I have never shared it 'Read Only'. On the Windows machine, I can't see any list of peers at all, I have to enter a link key. However I can't – it rejects even the new 'Read Only' key from the Linux machine... Sync 2.0 seems far more complex than version 1 (especially with 'identities'), and worse seems completely broken, for me. I hope I don't have to give up on it and go back to Dropbox. Do you have some instructions for giving up and starting from scratch? The instructions for reverting to 1.4 (on Windows) look horrendous. As far as I can tell I don't want to use identities, I just want to share folders as I did with version 1.

I'm not sure if it has any bearing, but most (all?) of the affected files seem to be '.mht' files... curious!

I have found that the error message is erroneous. While the History tab displays "Skipping file ... with bad timestamp", and the error log contains messages "SyncFilesController: got file with zero modification time, skipping", in fact, the timestamps are fine, but there is some problem with ownership and/or permissions on the files: Windows file properties is giving me errors "To continue, you must be an administrative user with permission to view this object's security properties" and "Unable to display current owner". Perhaps the development team could review this and correct the error message for this case?

Windows reports Created timestamp as 07/08/2011 16:51:01, and Last modified timestamp as 07/08/2011 16:51:03. There doesn't appear to be anything in the log relating to it.

I can't see anything wrong with the timestamp on this file - what might be causing this error? Should I do anything about it? Would you like an error log? Thanks, Chris (btsync 1.1.27 on Windows 7)

Cancel that, I guess I was just too impatient – it seems to have settled down now.

Bittorrent Sync seems to be a major CPU hog on my Linux system - almost always at the top of the 'top' list, mostly above 30% cpu, often up to 90% cpu, even when it has nothing to sync. Details: BitTorrent Sync 1.0.116 Linux MintBox 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux btsync: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=0x6f071c193bc5b22409fb11c072e7bd62cc0133b7, stripped

BitTorrent sync looks absolutely wonderful, I think it should be a really good fit to my sync needs. This is my BTSync wish list, in priority order. Obviously, you guys are already working on most or all of these, but I'd like to chip in my requests and priorities... 1 Conflict resolution: has to be absolutely top of the list for a functional sync app! 2 Windows service: currently, both devices being synchronised have to have users logged in simultaneously to sync - BTSync available as a service on Windows would fix this (both machines would have to be switched on, but not logged in). 3 Cloud cache: for true time-shifted sync, diff files could perhaps be stored on the Cloud until the partner device could pick them up; I would be prepared to pay BitTorrent a (hopefully small!) fee for such a service. 4 Versioning! This would make BTSync unbelievably useful. Git manages versioning in a highy space-efficient way: perhaps BTSync could use a similar approach? 5 Differential comparisons: rsync only transmits the changed parts of files, I'm sure BTSync could do similarly, which would improve performance (and reduce file storage of Cloud cache). 6 Android version