ctismer

Members
  • Content Count

    22
  • Joined

  • Last visited

Everything posted by ctismer

  1. @ Sync Support Good to know about this work-around. Devonavar is very right here: This behavior should be added to the FAQ or get fixed, ASAP. The behavior of an affected system is quite weird, since it is hard to see a logic: - I have 10 folders synced between two macs - one folder is synced to my linux box - failure to sync one file with linux stops the whole synchronisation! This makes this system pretty unreliable: problems with one shared folder should not in any way affect the behavior of other shared folders.
  2. testing 1.3.89 - a few more hours

  3. @sirphilip @tmac @tuxpoldo Hi guys, there are your implementations, and there is also since a while this on PyPi: https://pypi.python.org/pypi/btsync.py/0.9.8 So the question is how and with whom to create a definitive btsync api wrapper? https://github.com/jminardi/python-btsync https://github.com/tiagomacarios/pybtsync/blob/master/pybtsync/pybtsync.py https://github.com/kevinjqiu/btsync.py https://github.com/tuxpoldo/btsync-deb/blob/master/btsync-gui/btsyncapi.py I would like to merge all the efforts into the one, final implementation that is normatively state of the art, supporting python 2.7 and 3.3/3.4 Can we please discuss this and come to some common concept? Cheers - Chris
  4. Not sure how your define "better", or if I misunderstood you: Whatever extra attributes BtSync supports, it is necessary to make that transparent. BtSync can use any peer for any piece of data, therefore they all must be compatible. At the moment, BtSync takes the simplest approach of just supporting the common subset. If there is anything in extent, then it needs some representation on every supported platform, for exactly that reason of interchangeable peers. Alternatively there would need to be another layer which is always compatible, and what the user sees in his folder would be just an OS specific representation, but all missing info is shared in some extra structure. This would be a little bit like sharing git repositories with all needed extra info, but the user gets only the os-specific check-out. I'm not sure which approach is the right road for the future. I also think that the developers are not yet sure where this journey goes, so the minimalistic approach was probably a good compromise to start at all. cheers - chris
  5. They are stored as extended attributes. BtSync does unfortunately not care about these, because they are platform specific. I think they should be respected, instead, as much as an OS can support them. As a starting point, I would support them by additional files, maybe with an OS dependant suffix, like: my_file.rtf my_file.rtf.osxattr The osxattr file would only exist if there are special attributes. When transferring between OS X machines, the attribute files would be evaluated and applied after the transfer. A Windows machine would just carry them around. cheers - chris
  6. About controlling all your machines at once, I recommend LogMeIn to you. The free version is all you need to set up once, and then you can forget about The simutaneous stop-adjust-fix-restart btsync problem.
  7. The files are not gone. By default, they are in .SyncArchive on all other devices that share the same secret. Exception: There is a size threshold from which size on to skip these backups. So what I would do: - Increase the size threshold to the maximum, and - increase the purge time to "never". I don't know what to enter here actually, but you should try and report back if it works: Open btsync, go to Preferences/Advanced change "max_size_for_versioning" to the highest allowed value (or maybe "0" is allowed - please try) This number is in Megabytes. change "sync_trash_ttl" the same way. This number is in days. This way, you get a numbered version history in .SyncArchive, as long and as large as you desire. This subfolder is not synced, it only has old versions. You can now access older versions, even by using some (Python-?)Scripts to get at older versions. Not perfect, but maybe this helps. cheers -- Chris
  8. Yes, BTSync has its shortcomings, but it is possible to live with that. What I'm doing is pretty straight forward: On the client with limited space, I have ons shared "minimum" folder. On the larger machine, I have "minimum" and "maximum", which is also shared elsewhere. So, server A has "minimum", while server B has "maximum" and "minimum". When server A gets to its limit, I go to server B and move some files from "minimum" to "maximum. Those files are then moved on all servers that have both shares, but removed from those which only have "minimum". Admittedly not perfect, because when moving between shared folders, they are re-transmitted completely, but it works for me.
  9. On the delay of sync triggering, here are two small python programs for you to play with. The activity and traffic is quite high, but information needs about 40-60 seconds until it reaches its destination. Use python 2.7 or 3.3. Remove the .txt ending that I needed to append for uploading. pingpong.py looks for a file "ping.txt" and renames it, and vice versa. pipapo.py uses a single file "pipapo.txt" and compares the content with the machine name. It prints the old contents to the console and writes new info. I tried it with 2 to 4 machines (real and virtual). cheers - chris (oops, should have put this somewhere else) pingpong.py.txt pipapo.py.txt
  10. I had so few files that I didn't even notice the "Indexing" message. There was just one file added, changed or deleted. It took a few seconds until I saw the notice of the changes in the source log, then again a few seconds until the log showed this on the dest machine log. Tested after that the unpacking of a zip file with 1000 small members: Again there is the same average delay until I see log entries in the source, and the same again in the destination log. But the transfer then runs very quickly. Which is bad for what I want to do: I have very few changes and small data, but I need them to be transferred in a few seconds. I'd like to implement some handshake by file renaming, but the resulting delay is too much.
  11. I have now two virtual windows boxes in Parallels directly connected. Stopped btsync on all other machines and had a single shared folder. I renamed a test file several times, duplicated, deleted etc. The change showed up after 10-25 seconds. When I use the python watchdog module, which utilizes windows notification as well, I can see file changes in a fraction of a second. So there definately _is_ speed available without much overhead. So in your definition of "instant", is there an artificial delay? It feels like there are notifications captured in some buffer, but the buffer is then polled every 20 seconds, maybe. I assume this is some default value to avoid too many activity on the database? thanks - chris
  12. OS X does have a file change notification, just quite different form, say, windows. So is instant sync on windows really true? I cannot test that right now because I'm running only virtual windows in Parallels. (maybe I can test it when I manage to connect the machines directly)
  13. A way that works nicely for me is the threema app. https://threema.ch/ This way you can securely exchange secrets with friends. Side note: This is more secure than BTSync or even PGP because there is no backdoor. Another good way is GnuPg.
  14. Hey friend, does that make sense, after all? BTSync is great at hopping through NAT problems. That is true, the rest is not really what we want/are used to. I am very likely to abandon this stuff, keep what I learned (quite a lot) and starting over! Open-sourced (although not in the next 6 months, of course), and with a fresh concept. My idea is to re-invent BTSync in a fresh way, with no relationships to old "new" concepts like what Bittorrent has been doing for 12+ years. I think a new re-start is over-due. And with all the good things we got, it should not be that an unbearable brick. I once started a real brick (PyPy, if you know that), which was way too much in the end and made me probably sick. But this project could be very affordable, also in the sense of health. What do you think? cheerioh - chris
  15. @jthroth About the linux client: Yes this is very handy. Unfortunately only for Linux-ish devices. Is there a way to run the linux client on Windows? As always, after some promising start of a project, I finally have to do everything on an old XP 32 SP3 install. BTSync works there too, pretty good, but no way to retain the simplicity of Linux I fear.
  16. Additional comment: Besides the already mentioned long delay until a sync is started, here is another observation that lets me regard this software release less than beta: I used BTSync to copy a large folder (iPhoto lib) between two directly connected Mac machines. Both could communicate via Ethernet or WLan. You bet what BTSync did? In fact, it used the Wlan at 4 MB speed. When I switched the WLan off, it took a while, but in the end transfer restarted, with 120 MB speed. As a conclusion while trying to stay polite, I get more and more the impression that this is a more or less working prototype for wetting the potential customer's appetite, but with no intent to make this a serious project that can stand OSS standards. Besides this critics, BTSync works quite well for reduced expectations, and that ist my way to use it for now. I am abstracting from BTSync and any API, but simply try what's possible if the only safe assumption is that some changes will show up after a certain delay. With that approach, I can also model some simpler scenarios based upon rsync or unison. The simplicity of installing BTSync is anyway wonderful, and therefore I'm going to use a shared folder to boot everything on top of it. So, alhough disappointed in many aspects, it is still a very useful tool, even if it just acts as the fallback or bootstrap for a mote specialized system. Sent from my Ei4Steve
  17. Do you think about stopping BTSync, modifying the .dat files and then starting, again? That is pretty doable, but takes of course some time when restarting. I played a bit with the torrent file structure, pretty easy to convert them into Python dicts and writing them back out. (there are a couple python modules around of different quality). Hacking at the binary is harder, and I'm a bit reluctant, because that would get me into days of exploring and debugging... Btw., on Linux without Gui support, there is a simple ascii interface to settings etc. Unfortunately, the Mac version does not react to any CLI argument.
  18. Is there something like a release schedule for a minimum API? I tried to find some feedback from the developers to the big wishlist, but can only see the list growing forever. Is there any way to contact a developer? cheers - chris
  19. For extended purposes, the initiation of a sync is too slow. When new files are added or changed/renamed, I observe a time delay between 10 and 18 sec before the sync starts. No idea about the reason for this, and it is basically fine, so I would simply add: A tiny API, some CLI operations or whatever, that enables triggering the transmission of a file or message immediately, without having to wait for the synchronization to be initiated the normal way. This is the missing piece to write distributed applications with fast message passing. cheers - chris
  20. Actually, this leads me to a feature request: If the sync is not really reactive (which is fine for average use cases), then I would like to see an API to enable some broadcasting of information that does not have to be file based, but where machines can be notified of events. (will submit something to the wishlist, but I fear this is already a black hole ;-) )
  21. I agree that this delay does normally not matter, but I have special purposes in a mesh of machines. To confirm the better notification time of windows, I created two virtual Windows machines in Parallels 7. Then I installed the same test scenario and switched BTsync off on the Mac machines. BTsync was now running in the two virtuals which could see each other through local networking. I checked again by syncing a file and renaming it on one machine. As with OS X, the name change took 10-20 seconds to propagate. When I lowered the scan interval stepwise down to 3 seconds, the sync reacted a bit earlier, but took still up to 12 seconds. I'm just a bit wondering, because on my python programs, I use a watchdog which has optimized system events for OS X, Linux and Windows, and notifications work in a fraction of a second. https://pypi.python.org/pypi/watchdog The way BTSync operates feels pretty much like a polling implementation, or maybe there are other reasons to throttle this? Fast notification of changes was actually my hope to get rid of a central server in my application. cheers - chris
  22. On the speed of synchronization startup: I have set up two machines in a fast LAN, DNS and everything, and data transfer between both machines is very fast (MacMini server and Macbook Pro). But I recognized that the syncing seems to take 10-15 seconds until I see the transfer starting. This seems not to change, with Ethernet, Wifi or even a server on the internet. Does that have something to do with the time difference setting, maybe? Is there to get that down to, say, 1-2 seconds in such tightly coupled scenarios? thanks in advance!