Disappointed Cat

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Disappointed Cat

  1. All you need is an init.d script. Someone here wrote one that supported mutiple users but that one didn't work for me so I made a simple one. Here: http://pastebin.com/Jcc9MWrb (Set the 4 variables at the beginning.) Create a btsync file in /etc/init.d then set it up using 'update-rc.d btsync defaults'.
  2. Can know hosts operate as trackers? (Even if they don't have a share or secret.)
  3. Backupsy seems like a really good deal. But it has a terrible bandwith to Central Europe (i.e. Hungary). I could only get 160 KB/s over HTTP which is still a little bit better than Dropbox but it's all the way on the east coast while backupsy is in Illinois. For me one of the main reasons for changing to BTSync was the bandwith - I can get better speeds from my home server than any major cloud storage provider. Except Google, they have a server farm in my country, but GDrive is just terrible. It's still a very good backup solution. But I'd prefer something in Europe.
  4. Actually this could be a great business idea if BTSync will spread like wildfire. Take a few dedicated servers or VPS in a cloud, set up btsync instances with webUI on different ports. Marketing, sell, profit.
  5. Is this thread really for applying? If it is count me in too. HTC Desire (4.2.2), MyAudio (4.0.4)
  6. I just requested this yesterday. +1 EncFS, ecryptfs, truecrypt, whatever is not a viable solution because for them to work the storage needs to be mounted and that is an easy target if anybody has root access there. If you're thinking puting the encrypted storage in the sync that would work of course, but I'd only want storage level encryption at the remote, untrusted host.
  7. In that case you're absolutely right. Although I think it won't sync locked files as it should be. Then again rtorrent creates empty files at start with the same size to avoid defragmentation and I don't know if it keeps those locked until the entire download finishes.
  8. I restarted the client on the server multiple times; on the laptop I created the ignore list before I added the share. BTW now that I commented out the huge excluded folders from the ignore list, it does not forces a re-index after restarting the client on linux. So there is definitely something funky with sizable shares and excluded folders.
  9. No it wouldn't. You do realize you have to download everything from the seedbox if you want to use what you torrented? Of course you could stream, but you need a pretty good connection for that so you might as well just torrent at home (if you can). But I think the OP wants to sync a folder up to the seedbox via rtorrent/rutorrent. Well that works differently, you'd have to rehash the whole folder and create a .torrent file to upload everytime.
  10. Let me start with that I really love this app so far and it has even more potential. So I have the following problem: After I restart the client (linux, 1.0.132) it forces a reindex on my biggest share. It's my music library consisting of approx. 36K files and 450GB. I want to sync most of it to my laptop. There is no selective sync yet so I used the ignore list. It's annoying having to wait out hours of indexing. As far as I can tell this problem is not present with any of my other shares but those are all less than 1GB so it might just be fast enough that it finishes before the webUI starts up. And this brings me to another problem: If one share is indexing all other tasks have to wait in line. This is a pain if that indexing happens to take hours. Couldn't this be simply solved by multithreading? Edit: Come to think of it this re-indexing did not happen until there was no ignore list (which excludes ~250GB) and the laptop wasn't connected. Edit: Dispite the ignore list - which had to be correct because the reported size of the share was correct (on the source) - the laptop still received excluded files. The laptop had the same ignore list as specified. I think this re-indexing bug may be related to the ignore list in some wierd way. I'll just wait for the selective sync, this was meant to be a temporary/test solution anyway.
  11. I'd very much like an option to extend the read only access to ready only and encrypted. So basically we could set up peers for redundancy and performance anywhere with the data remaining encrypted. And tiny behaviour modification: If .SyncTrash is disabled in a share please do not auto-create it.