atomicbird

Members
  • Content Count

    10
  • Joined

  • Last visited

About atomicbird

  • Rank
    Member
  1. I just had the same problem when setting up a share on an Ubuntu VPS. I fixed it using the process described by @bratten (thanks), but in the spirit of providing more information: The Ubuntu server is running 2.6.1 (1319), (installed as described at Resilio's site) with Ubuntu 16.04. It uses an encrypted key and showed the conflicted files in its web UI. The folder is also shared on two Macs, also running 2.6.1 (1319) on mac OS 10.13.6. They use read/write keys. A sample long filename apparently causing trouble: "HIYsdOFEuPMf5x7PXgZIhkz_l5t7InMiOiJzMyIsImIiOiJhZG4tdXNlci1hc3NldHMiLCJrIjoiYXNzZXRzL3BhZ2UvNzYvNzAvMDAvNzY3MDAwMDAwMDAwMDAwMC5wbmciLCJvIjoiIn0-3777.png" In my case all conflicts were for files in the same directory on the Macs. I resolved it by deleting the directory (which I didn't need anymore anyway).
  2. I don't recall if I saw those warnings. Since there's no documentation on moving to a new directory, I guessed (incorrectly) that entering the same key would mean that Resilio could re-scan the contents. I didn't expect Resilio on Linux to automatically follow the share, I was trying to tell Resilio how to find it. Assuming that I did see those messages, I'm not sure why Resilio left the existing files in place if the message warns that they'll be overwritten. It would be useful if this were explained somewhere, so as to help people from making the same mistake in the future.
  3. I sort of got through this, but in the absence of better advice, I have to say that if you need to move a shared directory to a new location, just don't. You'll be better off creating a new copy and letting it sync. In the case of my problem sync, described extensively above: I expanded the dedicated partition to 40GB. Eventually it completed. However, it's using 36GB of space on the partition for a shared directory that the web UI reports as containing 12.95GB of data. Since that seems ludicrous, I set up another Linux VPS with Resilio and added the encrypted key there. It has now finished syncing, and is using 14GB of space for the same shared directory, which its web UI also reports as having 12.95GB of data. I don't know what the original Resilio install is doing with that extra 22GB of space. Since it's a VPS I'm just going to destroy the instance and forget about it. If I ever need to move a shared folder in the future, I'll set up a new VPS instance and let it sync rather than try to move the existing directory. However, if anyone knows the correct way to move a directory, or has any theories on why my move resulted in needing more than 150% extra disk space for the same shared directory, I'd love to hear about it.
  4. As of just now, Resilio ran out of space on its partition. It's a 30GB partition, and Resilio on my Mac reports that this shared folder contains 12.95GB of data. I would have thought that setting aside >2x the expected requirement would be more than enough, but apparently not. This partition on the Linux box doesn't have anything else on it, only Resilio sync data. Can anyone tell me what I should have done to move my working shared directory to a new location? I assume that I screwed up somewhere but I don't know where.
  5. To update this, shortly after posting, the Linux share started uploading files from my Macs instead of simply reindexing its own files. I had thought that my steps to move to a new directory would do the job without needing to re-upload most of the data, but it looks like I was mistaken. The partition I'm using doesn't have enough space to hold the >10GB of files still not accounted for. This is looking like a disastrous failure. Where did I go wrong?
  6. A few days ago I needed to move a shared directory to a new location, since the old location was running out of space. This is on Ubuntu 16.04, and it's using an encrypted key. I initially set up Resilio using the steps described at https://help.getsync.com/hc/en-us/articles/206178924-Installing-Sync-package-on-Linux To move the store I did this: Used the Linux web UI to disconnect and remove the existing location Copied the contents of the share directory using "sudo cp -a [old location] [new location]" Copied the encrypted key from Resilio on my Mac, and entered it in the Linux web UI Selected the directory where I had copied the files back in step 2. Now there are a couple of things that have me concerned. The "indexing" step seems to be taking an extremely long time. On my Mac Resilio reports the size as 12.95GB. In the Linux web UI it's gradually growing. But, a little over 5 hours ago it was at 3.53GB and now it's at 4.03GB. At this rate indexing will take several days. Is this normal? The system is not maxed out for CPU, disk access, memory, or bandwidth, so what's holding it back? My Mac reports that the total data size is 14.51GB, but on the Linux box the total file size (from "du -sh") is currently at about 26GB and growing. It's kind of a race to see if the indexing finishes before the partition runs out of space, which is odd since it's already using nearly 2x the space I'd expect. Can anyone offer suggestions or advice on this? Did I screw something up, and if so what should I have done differently?
  7. Still seeing this with 2.0.105 running on OS X 10.10.3. According to "peset -g assertions", BitTorrent Sync is preventing system sleep. I turned off debug logging, since some people mentioned that, and relaunched the app. No change, though.
  8. But did this last? I've had the same kind of problem, and rebooting and/or restarting the sync app gets things going... for a while. Pretty soon it's right back to "out of sync" though.
  9. I wrote to support about this and they requested debug logs, which I sent, but I haven't heard any more. Support also seemed to think that the Linux node might be part of the problem. They didn't say so specifically but mentioned it several times in their response. So I tried creating a new share between just the two Macs, with no other machines connected. I used rsync to copy over everything from the broken share to the new one (except for the .sync/ directory) to the new one. I also upgraded the Mac client to 1.4.93. The new share worked great! For a day or so. Now it's out of sync as well. So what, basically, the hell? The Macs are both on the same LAN. Sharing worked great at first but then inexplicably just stopped. Do shares just give up and die? Is there something I could look for in the logs that might give me a clue?
  10. I have the following setup: Two Macs, on the same LAN, running Bittorrent Sync 1.4.91, using a read/write keyOne Linux box, remote, running 1.3.109, using an encrypted read-only keyI've configured two sync folders between these devices. One sync folder works extremely well. Syncing is quick and reliable. One sync folder isn't working at all-- the Macs simply show it as "Out of sync", even though they can ping each other via their local IP addresses. Where do I even start looking to figure out why one works and one does not? The peers obviously connect, but only for one sync folder. If it makes a difference, the working sync folder has about 36MB total, while the broken one is roughly 810MB.