himselfv

Members
  • Posts

    18
  • Joined

  • Last visited

himselfv's Achievements

Member

Member (2/3)

  1. Have you figured this out? I'm having the same issue (on latest versions), and I'm not using parallel nested folders. I think it miiight have happened around the time when one node had low disk space, but I cannot tell for sure as I've only noticed the corruption a while later. And even on that node, the broken versions stored there have the correct size, just the wrong content.
  2. Windows PC: Sync 2.7.3 (1381) Android: Sync 2.6.5 (9641) How to reproduce: 1. Create an encryption-supporting share on Windows PC from a folder with a bunch of 2-3Mb sized JPEGs (120Mb is enough). Make sure the files' modification times are not recent. 2. Add a full node on Android. Mark it for full sync (no selective sync). Wait for full sync. At this point everything is usually fine. 3. Quit Sync on Android. Wait for some time. Usually a few hours is enough, maybe up to a day. Restart Sync on Android and wait for it to index things and work for a while. 4. Observe: modification times of some files on PC are now recent (the times when these files had initially been synced to Android). I've read elsewhere that many Android builds like to mess with modtimes and so Sync ignores file system modtimes on Android and only cares about the ones it recorded in its DB, but here it feels like it doesn't do that, maybe? Notes: * Instead of the full sync you can usually do selective sync and just select a few files, and only those will be affected. * I don't know if it's important that the share is encryption-supporting. Haven't tried this on basic shares. * I've studied the logs on the PC side, and for all affected files, the PC discovers there are "newer versions" (higher mtime) at the Android node, downloads those and that's why local files on the PC change modtime. (The files aren't really being changed anywhere!) * There's not way to read the logs on the Android, so can't tell what happens there. * Android filesystem modtimes for those files are indeed recent - either Sync doesn't even bother to set them on Android, or it's one of those systems where they don't stick. * Each time you run this experiment, only some files get broken, not all of them. If you run Sync again and again for several days, more of the files are becoming affected, but some still retain their original modtimes on the PC. * I think I had the same thing happen to me when the android node is read-only, but that would be extremely weird and I can't reproduce it now, so maybe I'm mistaken.
  3. I'm trying to troubleshoot a bunch of problems on Resilio Sync Android (2.6.5), and while there's an option to enable log, there's none to download/save it. Instructions to manually get logs explains how to enable it but not how to get it. From logcat, it seems it's in /data/user/0/com.resilio.sync/files/.sync/. But of course Android is designed to make life miserable so you can't get there without root. There's an option to change storage path in Sync, but on Android it's unavailable. So how can we get logs? If the answer is "well, uhm", then please add a way, is that so hard? Or/and add the option of changing storage_path. Sync is not very stable lately, it "Can't download files" randomly, shows empty list of what it can't download (on Android there's not even a list), leaves tons of [MD5MD5MD5].!sync files everywhere, then it turns out it failed to sync a bunch of files out of blue. And yesterday I discovered that it for some reason *removed* an important file that I needed to have with me at all times, and that I had checked to be selectively synced and working just a week ago, and could not download it again while downloading all the other files in the folder, and I was basically as screwed as it gets. Please at least give us the instruments.
  4. 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.
  5. 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 another reason I want to limit/reset the index.
  6. 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.
  7. 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.
  8. > 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?
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. @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?
  14. @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.