cpbotha

Members
  • Posts

    7
  • Joined

  • Last visited

  • Days Won

    1

Contact Methods

  • Website URL
    http://charlbotha.com/

Profile Information

  • Gender
    Not Telling

cpbotha's Achievements

New User

New User (1/3)

  1. I seem to be having the same problem with bittorrent sync 1.4.75. On node 1, I go to "preferences" for a specific share, then "view key" and then I copy the read-only key. On node 2, I click on the "enter link" icon at the top right, then I paste the read-only key and enter the directory. However, on the just added share on node 2, when I go to preferences and view key, it shows me a read-write key and a different read-only key than the one I pasted. Also the share icon on the left does NOT show that it's read-only. One of the read-only shares that came with me from 1.3 does show the icon. In addition, the two peers never find each other, even although on the same class C subnet. So the question remains: What is the correct way to add a share with a read-only key? When I find out, I will post again, probably with more than just "Nevermind, I figured it out." Slightly later: Nevermind, I figured it out. (but I'm not going to tell you) (haha just joking. It looks like directly entering the RO key from node 1 simply does not work, and does not warn the user that it won't work. I got it working by going through the "share | read-only | copy link" functionality, making sure to disable expiration under "advanced" on the share dialog box. It would be great if the GUI *did* work correctly with the direct entry of an RO key.
  2. I've run into this same problem when syncing with an eCryptFS filesystem. It turns out that that has a filename limit of 143 characters, so now I'm seeing: [20140322 08:26:30.659] LoadTorrent: file /volume1/btsync-cpbotha/work/code/xxxxxxxx/yyyy/htmlcov/_home_cpbotha__virtualenvs_yyyy_lib_python2_7_site-packages_easy_thumbnails_migrations_0015_auto__del_unique_thumbnail_name_storage_hash__add_unique_thumbnail_sou.html exists, but failed to get mtime 36 This is a design limit of eCryptFS: https://bugs.launchpad.net/ecryptfs/+bug/344878 I'll have to figure out some other way of encrypting the btsync trees on my synology. Any tips? (eCryptFS is what happens when you create an encrypted share)
  3. I just scanned through most of the documentation, and Hive2Hive sure looks promising. I think it's great that you're making a reusable library for this, but what would be really great for the uptake of your code, is a usable client application / demonstrator that does, for normal users, what bittorrent sync does. Is this something that you might be thinking of or perhaps even working on?
  4. I am unfortunately also seeing this git-old-file-returning problem quite regularly between NTP time-synced computers: http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/?p=68934 I haven't touched any file permissions.
  5. As I posted here before: http://forum.bittorrent.com/topic/18984-source-code-control-metadata-shouldnt-sync-by-default/?p=66838 -- A desirable use case for me (and apparently others) is to have bittorrent sync keep a local git repository in sync between multiple computers. I often work on my workstation, and then move to my laptop to continue working on the same git repository. I expect that after a few minutes, if all computers are connected, the whole git repo should be completely synced, and that I should be able to continue on where I left off. (this worked on Dropbox for years, and for many git repos, so it must be possible) In any case, it has unfortunately happened a number of times now that bittorrent sync puts back older versions of the files I'm working on, although all three involved nodes (Synology NAS, workstation, laptop all with 1.1.70) are time synchronized with NTP. What I then usually do, is to double-check exactly what changes have been reversed, and then to do "git --reset hard HEAD" when I'm sure that's what I mean (in many cases, but not all, the git object store seems to be up to date, but the files not). Is anyone else seening this behaviour? Any tips to remedy, or decrease the chances of it happening?
  6. A part of a 40G folder synced between a Synology ds213j, and two laptops and a desktop all running Ubuntu 12.04, I have a large SVN checkout. My use case is that I want to be able to switch machines mid-work, and continue working on files in that checkout. See my other forum post http://forum.bittorrent.com/topic/18984-source-code-control-metadata-shouldnt-sync-by-default/?p=66838 for my motivation. However, syncing often gets stuck due to files in the checkout. This is what I do to get it to sync again: I check .sync/sync.log (by default .sync dir is in the same directory as btsync), where I see a whole bunch of the following lines: Error downloading file /that/svn/some/file: FixPartFile: hostname not found I kill btsync. Then I remove SyncPart and SyncTemp files from the svn repo: find /that/svn -name "*SyncPart" -exec rm -f {} \; find /that/svn -name "*SyncTemp" -exec rm -f {} \; All of the files that btsync complained about are read-only. I noticed that when I fix this, syncing can start again: find /that/svn -not -writable -exec chmod u+w {} \; When I now restart btsync, it takes a very short while, and then shows that everything is nicely synced up. I think btsync is one of those best things since sliced bread. I think some error reporting would go a long way to further improve the user experience. Better handling of read-only files, and some default file exclusions (just copy them from dropbox man , would definitely also help.
  7. Actually I don't agree with this default exclusion, for what it's worth. For years I've been working on a number of different git repositories on different machines, and relied on Dropbox to keep them in sync. It never ever disappointed me. Now pay attention to this specific use case before you go off on a tangent. I'm not sharing the repositories in question with anyone. This is purely so that when I get up from my workstation to continue work on my laptop elsewhere, I don't have to commit-push-pull simply to be able to do this. Instead I can just continue working, because the sync has taken care of the rest. When I'm good and ready, I'll commit. When I'm more good and ready, I'll commit and push to the remote server for other developers to pull from. I've cancelled my dropbox pro subscription of some years, and am now happily syncing everything with bittorrent sync. Having my private repos synced so that I can move mid-work from one machine to another, without having to remember which repos need to be pushed, is a use case that I support strongly. The fact that Dropbox has never dropped a stitch in all this time shows that it is possible. That being said, perhaps I'm in the minority, so I would also be fine with simply being able to disable these default exclusions to support my use case.