ctismer

Members
  • Content Count

    22
  • Joined

  • Last visited

1 Follower

About ctismer

  • Rank
    Member
  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.