• Content Count

  • Joined

  • Last visited

About himselfv

  • Rank
  1. That's on the PC, but in my case the backup is from Android. I suppose .db files are in /storage/emulated/Android/data/com.resilio.sync/ but it appears empty without rooting.
  2. Hello! I'm using Resilio Sync to backup DCIM folder from mobile. After the photos are synced I delete them after a while. Recently I've deleted and re-added the read-only share on the PC, and it tried to download all files I've ever had in DCIM, since more than a year ago. Most of those files were "unavailable". So as I suspected, Sync "remembers" old files even after they're deleted. How do I reset this index or limit it to something like a month of time? I've suspected this because over time mobile Sync's "local data" grew pretty big (700Mb) which is inconvenient. So that's an
  3. I also have this problem. Who thought it would be a good idea to force the folder on the users? I don't even have anything there. Please make this optional.
  4. Second that. Using custom controls in interface wasn't a good idea, at least where possible they should have been normal controls where keyboard navigation (and standard stuff such as right-click IME support) comes free.
  5. > Are you using Encrypted folders in your setup? Yes, and the folder in question is of encryptable kind (decrypted on this PC though). > If you are syncing in LAN - you may try to disable encryption in LAN. No, syncing over the internet. > How many files and folders in general do you sync? 5 sync nodes: 2300 files, 50 files, 8000 files (the problematic one), 2000 files, 1300 files. Only the problematic one is encryption-enabled, others appear instanteniously and start "(Indexing...)". > Does your hardware match the amount of files and folders (compare your RAM size to t
  6. Some of my shares have tens of thousands files, and I've noticed they're loading very slow. When starting Sync, even before it starts "(Indexing...)" the folder, it is stuck for a whole minute simply adding it to "My Sync" folder list. I fired up SysInternals Process Monitor, and it seems there's nothing but this set of requests again and again: 12678438 11:36:24,3138382 BTSync.exe 3476 RegOpenKey HKLM\System\CurrentControlSet\Control\Cryptography\Providers REPARSE Desired Access: Read 12678439 11:36:24,3138513 BTSync.exe 3476 RegOpenKey HKLM\System\Curr
  7. RomanZ, Windows 7 SP1/NTFS as a client, CentOS/xfs as an encrypted server. I've tried: share\some folder\some folder\some folder\some folder\some folder\some folder\some folder\some folder\some folder\some folder\some folder\some folder\some folder\some folder\file.txt -- works with BTSync share\some folder\very long filename longer than 143 characters or whatever the limit is but shorter than 255 chars.txt -- stuck in "Updating" like with other people in this thread
  8. I'm also having this problem. The problem is only in the length of a single filename which makes it a bit easier (full path can be of any length). But some solution would be great.
  9. Conflict resolution. At least simple Dropbox-style "duplicate copies". It would be nice if you could add a "post-sync" step so that custom conflict resolution apps could be run (e.g. text merge, custom DB merge etc). Without conflict resolution there's a high risk of losing data. SyncArchive is not enough as with large files it grows in size too quickly.
  10. @goli: I hope for the opposite. If they're using just TLS, then everything needs to be done from the scratch; on the other hand if it's SpiderOak-like block-level encryption then delta syncs are already implemented. And since this is BitTorrent... do torrents really use TLS? How would it work, if my data is rooted through several other nodes?
  11. @goli: There's already one encryption used when transferring data. To my mind it'd be better if a node could just "store encrypted blocks" it receives. I don't know if it's possible but it would be cool.
  12. ChrisH: Maybe you're right. Anyway, it's not simple. You need some file-level encryption, different keys for it, and make BTSync see encrypted data while the rest of the system sees decrypted one. And that supported on every device/OS BTSync runs on (not just the storage one).
  13. > Problem solved As I see it, there are only two ways to go about external encryption here: 1. Encrypt data BEFORE you sync it to untrusted PC. 2. (Re-)Encrypt it AFTER it has been delivered to untrusted PC. In the second case, whatever cool encryption you use, it's not real security because the data is decrypted at some point on an unprotected PC. And BTSync must be able to access so the key is also available unprotected. Right? In the first case you lose all the benefits of sync. "File-grained encryption, re-upload only changed files", if one file changes you have to re-upload the whole s
  14. +1. Please reconsider adding this. Using encrypted FS over shared data is not a solution because if we use it anyway, what are the benefits of BTSync? How is this different from EncFS over Dropbox or even FTP? (And we cannot sync only changed files which effectively destroys the idea of sync) Encrypting target FS on unprotected PCs is pointless as someone who has access to the PC has access to its mounted filesystems. And there are many use cases for this: - I want to synchronize two computers (home PC + work PC) but I don't have both running at the same time. I set up a server on a hosting an