• Content Count

  • Joined

  • Last visited

About himselfv

  • Rank
  1. 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.
  2. 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.
  3. > 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 the amount of RAM consumed by Sync). Probably. 8 Gb RAM, virtual memory allocated by BTSync when fully loaded: 226 Mb. > We do not read \ write the keys you mention directly, but we use Microsoft CryptoAPI which does. Yeah, I thought it's something like that, but maybe you're instantiating some kind of CryptoAPI object for each file where one would have been enough? I'm just guessing, it just looks like this slowness happens when BTSync is reading *.db files (probably SQLite databases?), and the largest of those on my PC is 94 Mb. So disk-wise it could be read in an instant. I've run the API Monitor, and it seems BTSync does this for every file (e.g. 8000 times): BCryptOpenAlgorithmProvider(... 'AES') BCryptGetProperty('ObjectLength') BCryptSetProperty('ChainingMode') BCryptImportKey(...'KeyDataBlob') BCryptEncrypt(...) BCryptEncrypt(...) BCryptCloseAlgortihmProvider() BCryptDestroyKey() MSDN says: > Because of the number and type of operations that are required to find, load, and initialize an algorithm provider, the BCryptOpenAlgorithmProvider function is a relatively time intensive function. Because of this, we recommend that you cache any algorithm provider handles that you will use more than once, rather than opening and closing the algorithm providers over and over. Maybe this is the reason?
  4. 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\CurrentControlSet\Control\Cryptography\Providers SUCCESS Desired Access: Read 12678440 11:36:24,3138673 BTSync.exe 3476 RegCloseKey HKLM\System\CurrentControlSet\Control\Cryptography\Providers SUCCESS 12678441 11:36:24,3138791 BTSync.exe 3476 RegOpenKey HKLM\System\CurrentControlSet\Control\Cryptography\Configuration REPARSE Desired Access: Read 12678442 11:36:24,3138915 BTSync.exe 3476 RegOpenKey HKLM\System\CurrentControlSet\Control\Cryptography\Configuration SUCCESS Desired Access: Read 12678443 11:36:24,3139053 BTSync.exe 3476 RegCloseKey HKLM\System\CurrentControlSet\Control\Cryptography\Configuration SUCCESS These 6 requests are repeated a godless number of times, probably the same tens of thousands times, once for each file. There's no reading apart from rare block reads from btsync ".db" files, no network activity, justs these requests. This takes minutes. I'm guessing here, so pardon me if I'm wrong, but perhaps it's something that can be easily optimized? Maybe you're creating some sort of crypto primitive which looks into these keys on initialization, and in fact you could use the same primitive for all files? Because the actual "(Indexing...)" step runs much, much faster than this step.
  5. 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
  6. 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.
  7. 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.
  8. @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?
  9. @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.
  10. 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).
  11. > 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 share, if one file changes you have to reupload the whole share. If someone else changed one other file, both shares conflict. Right?
  12. +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 and run BTSync there, PC1 syncs with Server, Server syncs with PC2, everyone happy. Hacker hacks server, has access to all my data. - I'm a businessman, I see this perspective new technology called BTSync and realize I can run my own node and provide hosting for case #1 people. I'm all ready to earn money (and donate to BTSync team) but people don't trust me with their data. If only I could handle it in encrypted form!