rdebath

How about this one ... [20130328 13:42:29] SyncFilesController[file updated]: processing file /home/btsync/data/Testdirtwo 1367152938 0 [20130328 13:42:42] [OnNotifyFileChange] /home/btsync/data/Testdirtwo/thetestfile.txt [20130328 13:42:42] [OnNotifyFileChange] /home/btsync/data/Testdirtwo/thetestfile.txt [20130328 13:42:42] [OnNotifyFileChange] /home/btsync/data/Testdirtwo/thetestfile.txt [20130328 13:42:53] SyncFilesController[file updated]: processing file /home/btsync/data/Testdirtwo/thetestfile.txt 1367152962 0 [20130328 13:42:53] New torrent created for file Testdirtwo/thetestfile.txt mt:1367152962 CFFA50DD1D2A2D9A9E0965D893D547A7ADE84CDE [20130328 13:43:23] [OnNotifyFileRename] /home/btsync/data/Testdirtwo -> /home/bt/data/Testdirtwo [20130328 13:43:35] SyncFilesController[file rename]: renaming /home/btsync/data/Testdirtwo to /home/bt/data/Testdirtwo [20130328 13:43:35] SyncFilesController: Processing file renaming Testdirtwo/thetestfile.txt -> dirtwo/thetestfile.txt Yup as predicted; they're chopping off the wrong share prefix (plus the slash that isn't there of course) Don't try this one ... [20130328 13:43:23] [OnNotifyFileRename] /home/btsync/data/Testdirtwo -> /home/bt/data/Testdirtwo [20130328 13:43:35] SyncFilesController[file rename]: renaming /home/btsync/data/Testdirtwo to /home/bt/data/Testdirtwo [20130328 13:43:35] SyncFilesController: Processing file renaming Testdirtwo/thetestfile.txt -> dirtwo/thetestfile.txt [20130328 13:49:36] [OnNotifyFileRename] /home/btsync/data/Test -> /home/bt/data/Test [20130328 13:49:47] SyncFilesController[file rename]: renaming /home/btsync/data/Test to /home/bt/data/Test [20130328 13:49:47] SyncFilesController: Processing file renaming Test/dirthree -> /dirthree [20130328 13:49:47] SyncFilesController: Processing file renaming Test/dirthree/testfilethree.txt -> /dirthree/testfilethree.txt [20130328 13:51:24] SyncFilesController: Detected deleted or renamed file [20130328 13:51:24] SyncFilesController: Detected deleted or renamed file /dirthree [20130328 13:51:24] SyncFilesController: Detected deleted or renamed file /dirthree/testfilethree.txt [20130328 13:51:24] SyncFilesController: Detected deleted or renamed file dirtwo [20130328 13:51:24] SyncFilesController: Detected deleted or renamed file dirtwo/thetestfile.txt Bye bye whole share; even .SynchTrash is moved into the Trash, but there seems to be no serious security problem BTSync did not do an "rm -rf /" ... However, the remote did accept an instruction to delete the entire share including the .Sync* files ... that's not right.

I have setup two shares on a Linux i386 machine in directories /home/btsync/data.000 and /home/btsync/data On another i386 machine in one of the shares I created a directory and populated it with cats. (for directory /home/btsync/data ) After the transfer completes I move the directory from /home/btsync/data.000/cats to /home/btsync/data/cats ... chaos ensues. Once It settles down I turn on the logging and try to work out what happened. There seems to be some confusion because I'm moving the data between two shares and it's assuming that if the directory is move from a share to a share it must be in the same share. So I'm getting a '000' directory created in the /home/btsync/data share because it chopped the wrong bit off the front. I've saved the whole log file if you need it, but here's what I think is the significant bit ... [20130328 12:46:30] [OnNotifyFileRename] /home/btsync/data.000/tempdir -> /home/btsync/data/Testdir [20130328 12:46:41] SyncFilesController[file rename]: renaming /home/btsync/data.000/tempdir to /home/btsync/data/Testdir [20130328 12:46:41] SyncFilesController[file rename]: unable to find rename source, delegating to [file update] [20130328 12:47:28] [OnNotifyFileRename] /home/btsync/data/Testdir -> /home/btsync/data.000/Testdir [20130328 12:47:39] SyncFilesController[file rename]: renaming /home/btsync/data/Testdir to /home/btsync/data.000/Testdir [20130328 12:47:39] SyncFilesController: Processing file renaming Testdir/testfile -> 000/Testdir/testfile --- [20130328 12:54:46] SyncFilesController: Detected deleted or renamed file 000/Testdir [20130328 12:54:46] SyncFilesController: Detected deleted or renamed file 000/Testdir/testfile [20130328 12:54:46] SyncFilesController: Detected deleted or renamed file 000/tempdir [20130328 12:54:46] SyncFilesController: Detected deleted or renamed file dir

Actually, IME, the STUN protocol only really helps with old expensive NAT devices which do 'whole port' mapping or 'Full cone' mapping. A current cheap NAT router is likely to be running Linux and it uses the same connection tracking for the NAT as it does for the firewall. This means that if a STUN server opens a hole it only does it for itself not for everyone. But that's okay because this sort of very narrow NAT mapping only has collisions between mapping when all three of "local port", "remote port" and "remote IP" are the same. In that case the only useful thing the server can do (short of full relay) is to provide everyone with everyone else's external IP addresses. Both DHT and the Tracker do this fine (the tracker is faster). You may, however, have a problem if you have multiple BTSync copies behind one firewall because they will argue over who has the port number, when they're configured to use the same one. It's very unlikely that the port number presented to the tracker or DHT server will be the same as the one presented to the various clients. It's possible, even likely, that different remote clients will see different public port numbers. Unless you, carefully, make sure each BTSync client (behind a shared firewall) is using a different port. (Or get uPNP working, but then you don't need STUN either). Of course you have the server, you can probably check if it does see many 'full cone' NAT connections (without uPNP) ... do you? If there's only one BTSync per port behind a firewall (which means the port numbers are preserved) and the public IPs are known the two clients can punch through head to head NATs without any external help. If course if the NAT is configured to randomise the port numbers nothing will help, except full relaying and I expect only the tracker allows that. ... Does this mean I actually agree with you at the end ? ... hmm, no, you said "directly".

It could be an awful lot of things, a uPNP thing or DHCP lease thing like "AC" said; I've had firewalls stop DHCP renewals but allow the lease to be recreated once it's expired. I've had openvpn (which uses UDP in a similar manner, no STUN though) connections just stop for no visible reason; one end just stops seeing the other end's packets. One time I was able to get onto the remote firewall and see the packets going out, they just never arrived. My workaround with OpenVPN is simply to have two configurations; if one stops working I turn if off and switch to the other; I'm not sure how that translates to a BTSync environment though. Perhaps the 10 minute "sulk" could become standard by doing some sort of backoff when things don't connect (but what about penetrating head to head NATs ?). Perhaps BTSync could present two port numbers and switch between them as needed. I suspect reducing the ping rate when the connection is working would help to mitigate the problem if (for example) it's some sort of ISP traffic throttling. I could continue, but, maybe it's just a little .

For me it's still in the testing stage, but the use I have in mind is to fix the Windows shared documents directory at work. Basically, we currently have a mapped drive (S:) from a central file server so the users have to remember to save their files there. But modern laptop machines have huge hard drives in them, larger than the (S:) partition on the file server so there's absolutely no reason not to have a full copy of the S: drive on their local machine (The laptops have FDE) except the, huge, problem of keeping them in sync ... The signs are good.

Something to add to my list. A callout (trigger) that fires before a file is modified (created or deleted). This could be used to implement a shared permission scheme with digital signatures (or just bloodymindedness) If this node doesn't like the change (eg the new file has the wrong digital signature) it can abort it in some way eg: Send a delete to the network. (perhaps by doing a rename of the old file out of the way, accept the change then rename the old one back) Send a rename of either the before or the after file so they don't collide. Sign the file and move it from the upload directory to the next available distribution area. etc etc. [*]A callout (trigger) that fires as soon as it's known that a file will be changed but before any data is downloaded. So a part of a share can be made read only by us automatically reverting any changes before we make them. The use cases are things like: distribution of software and accepting patches, reports, tests back. create a wiki data area with full versioning and rollback. Anything else were changes need to be audited or controlled. EDIT: I think there would also need to be some sort of indication made to these two triggers so that a different change conflict management could be implemented. Instead of 'newest time wins' it could be 'oldest time', 'biggest file', 'rename old file', 'do a three way'.

Sync'd traffic footprint is pretty distinctive, continuous one second pings, tracker pings DHT probes etc etc. So the ISP could be pretty certain that it's btsync but the exact data that's transferred, no they wouldn't be able to see that. The would be able to see the "info hash" values that you put onto DHT or the tracker so if they know of an 'undesirable' btsync share they could tell that you're connected to it. But they wouldn't be able to see the files unless they know the secret as well as the public "info hash" or they can "rainbow table" the hash because it's an insecure key. From a UI point of view a magnet link and a btsync secret are practically identical. The advantage will be the ability of the distributor to add content to the share without changing the secrets. TPB could in theory distribute their list of magnet links database as a btsync share and keep it up to date without having to continually reissue a new key. I can't really think of a good use of a plain public RW share; but if you say add something that can check digital signatures on files (giving a form of network wide ownership) a shared permission scheme could be crafted. This would allow you to give the RW key to potentially malicious hosts because their changes would only be accepted kept if they have a good signature. ((Hmm, I sense an API post coming ...))

Four 'F's wellll obviously that's sixteen bits ... what'd you know it is! Seems these are the obvious values. FFFF -- Everything 0001 -- Pings etc 0020 -- Íncoming connection from ... 0040 -- Merge: ... Which leaves FF9E, what do the other bits control ? How come the bit number isn't part of the message ?

Oddly enough the previous message I read gives you a workaround for this .. http://forum.bittorrent.com/topic/18262-sync-on-android/ Though a static build would be a lot easier.

For the debug log http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/ Note: If the "Devices" tab has IP address and port number then that host has attempted to contact this host BUT we haven't heard anything more. If there a name there it means that two way communication has been established. If you only see an IP address I'd start looking at the firewalls for something asymmetric (and odd). Perhaps change the port numbers because you've got a bad NAT connection that's being kept alive. Perhaps turn BOTH sides off for 10 minutes before you restart them. Of course it's always possible that the admins at work noticed some weird traffic and blocked it ...

One thing I've noticed is that the use of multicast packets seems a little fragile. I've had the Windows client stop sending or responding to multicast (no packets on port 3838), couldn't repeat it but that time the connections went via a remote relay. (Checking for local lan connections was turned on, and frobbed ) I have a Linux bridging setup where the iptables firewall on the bridge was changing the source address of the mutlicast packets to the firewall's internal address. This caused btsync to attempt to connect to the firewall not the across the bridge to the other client. Once multicast was excluded from the MASQ rules it worked fine. You may have better luck using either (or both of) the limited broadcast or the various subnet broadcast addresses for the connected networks.

Okay list of things to do to the server ... Create a new secret share (perhaps with a new empty directory) Edit any configuration on a share. Delete a share Pause a share; disconnect from clients pretend it's deleted but keep it so it can be resumed instantly. Delete the files and directories that are in or were in a share Fetch individual files from the server or upload them for sharing. Turn the debugging on/off and view/download the debug log. Local or remote call backs (run programs) from the server whenever files are created, removed or modified. Eg: anti virus; it'll need the ability to revert to old versions. eg: anti-delete; once uploaded write permission is removed from the file. Call backs when a node (including this node) has finished syncing, callback when all nodes finish syncing (define "all nodes", eg: named list, all currently connected, 7 unique identifiers). Might want to delete the share when everyone or enough peers have it, might want to prevent us updating the share until everybody has a consistent copy. Might want to take a backup when it's consistent. Might want to shutdown the VPS when we're done. Possibility of sync being suspended while the callback is running. (ie keep it consistent) Trigger a scan of the filesystem for a share Suspend/resume scanning the filesystem for a share (nothing will be changed locally) Scheduled stops and starts of shares, perhaps just the ability to upload a 'crontab' but windows too. Alter the .SyncIgnore file and similar Server callback programs should be able to safely stop and restart the btsync program. Okay, that's enough for now ...

Oh, yes; and the best bit ... 20130227 in his "discouraged" list is actually ISO8601 format too.

Windows GUI problems The dates are displayed in the MM/DD/YY format that only Americans use rather than the international ISO8601 format or correctly using the l10n features of Windows. The "Finished syncing with EvilBox" message doesn't show which share was connected to. Windows GUI request A debug log file viewer, by default does a "tail -F" on the logfile but can scroll back. Has copy&paste.

Windows tools for doing a UDP traceroute are in short supply, even WinMTR fails in that respect (unlike the linux version). This tool seems to do the job: http://r1ch.net/stuff/ftrace/ Unlike mtr it doesn't overlap the probing of the hops so it's a bit slow, but it gets the job done. WARNING: UDP mode needs Administrator privs to see the replies; if it doesn't have them it never sees any replies.

Hmmm, Actually, no. It's worse then that. Everyone else's AV would have gone ape-shit and deleted all the known viruses ... you'd just be left with the really evil stuff ... NB: I prefer udpcast over netcat; shame that btsync doesn't use multicast for data on the local lan. Package: udpcast Description-en: multicast file transfer tool UDPcast can send data simultaneously to many destinations on a LAN. This can be used, for example, to install entire classrooms of PCs at once. The advantage of UDPcast over other methods (such as NFS, FTP, etc.) is that UDPcast uses Ethernet’s multicast abilities, which means it won’t take longer to install 15 machines than it would to install just two.

I agree, any encryption tool should compress it's input because it prevents other tools from doing it later. However, it's likely that the files are already uncompressible for some reason so I would strongly recommend a "compression lite" eg lzo compression (lzop), that doesn't try too hard and can probably keep up with most (even high) line speeds.

38 Minutes by my count

Not in the sense you mean, you could do 'Q' filling to pad a short read-write secret to 32 characters but the read only secret is based on an 'encryption' of the read-write secret. There's no technical reason that it has to be as it's actually an independent password but in the current executables it is.It would be more obvious if the secret share name and password were independent. In that case the read-write and read-only would share the same name but have different passwords.

Um, no; you'd actually be downloading one Usenet group (say alt.sex.perv.perv.perv) and it can be as specific or limited as you like. Actually, you can't stop it; BTSync is a pretty small and simple application (much like bittorrent) even now it wouldn't be difficult to make a version without the limits (including the open source one) But you don't actually have to do this to use 'simple' passwords. The secret that BTSync will accept is a 160bit string in base32 so 'all' you have to do it take the secret you want, put it into a sha1 encoder http://www.webtoolki...avascript-sha-1 if the output is "hex" convert it to base32 http://tomeko.net/on...e32.php?lang=en to give the result ... cats = R27WAH4LQCGDFOGS7NLQYLQPXW5TRCW5 Enjoy your Cat Pictures. 00000000000000000000000000000000

I would like to see a way of calling an external application once the current changes to the secret share have been completed. This could have many uses; a) triggering a backup process to save the current state. Starting an upload process to mirror the share to a more traditional shared store (ftp, webdav etc) c) Sending an email to notify that files have been updated d) Posting new pictures received from a phone to Facebook. e) ... There would need to be an option to 'freeze' the share while the application is running so it wouldn't have to deal with the files changing unexpectedly. Hmmm; Three minutes from shutter to Facebook

I wouldn't see this as required. SyncApp is more like a friend to friend application, where the identity of who you're talking to isn't a secret. The i2p network is more for being able to communicate and share with MrNowhere in a way that doesn't reveal to anyone who the peers are.SyncApp already has a moderately high encryption cost, i2p would appear to quadruple that for a feature (anonymity) that isn't in the specification. In addition, SyncApp keeps a 'connection' open permanently between the nodes, this makes traffic analysis much easier and statistical traffic analysis possible. So if SyncApp were run across an i2p link it's likely that it would be a key factor in defeating i2p itself.

This would be moderately difficult to implement IMO, but it's not part of the 'sync' process at all. It would need an extra passphrase independent to the SyncApp keys. As I see it it could be implemented as a filter on SyncApp's filesystem access so that whenever it reads a file from the sync directory (and probably the directory listing itself) it encrypts the data and provides the encrypted data to SyncApp proper. It works kind of like an upside down encfs, with the data on the underlying filesystem in clear text and the virtual filesystem provided to SyncApp being encrypted. This way any application that doesn't have the filesystem password will just see a normal filesystem with encrypted files (Which could be decrypted by some independent tool). A SynchApp with the password would put the files through the filter layer before they were written to the disk. Only the filter layer would see the cleartext data. BTW: The large majority of filesystems don't have resource forks, also NTFS has alternate streams and encryption which can make themselves known in annoying ways. This technique, adding a filesystem filter can be used to sync resource forks and alternate streams to filesystems and OSs that don't need compatibility with these strange or exceptional features. Conclusion: Perhaps it's already available as a library somewhere; but something needs to be done about symlinks and junctions.

Request: $ kill -HUP `cat .sync/sync.pid ` This command to cause SyncApp to do a restart; minimally it rechecks for the debug.txt file and reopens the sync.txt file. Ideally it does a full re-read of the configurations so secret shares can easily be stopped and started from the command line. Eg on a timed basis from Cron(1). This could also be available as "SynchApp --config Configfile --reload" Also on Windows, the ability to rename the sync.log file and do something similar without stopping SyncApp.

Please add an option to turn down the ping rate when the secret share is idle. In general I find (when using OpenVPN) the quickest ping needed by a firewall is around every 15 seconds, linux based firewalls time out after 3 minutes, and most firewalls seem to time out a UDP 'connection' in around 2 to 5 minutes. SyncApp seems to be pinging every second which is serious overkill. Some sort of auto mode where it backs off to the minimum traffic to keep the connection open would be very nice. Of course an established TCP connection doesn't normally time out for days.