firecat53

Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by firecat53

  1. I upgraded btsync on my laptop (Arch) to 1.3.67. The server (Ubuntu 12.04) was still running 1.2.92 (latest previous version). It may have been my fault, because I was also testing btsync inside a Docker container and doing a lot of starts and stops of the daemon on both laptop and server. Unfortunately I can't tell you the exact sequence of events because the problems occurred in a couple of really big (104GB and 37GB) archive folders for music and pictures that I don't look at all that often. Perhaps I suspended my laptop while it was still trying to process all the data...I'm not really sure. But...that's what backups are for! :-) Sorry I can't be of more help...but I'll definitely be more aware next time of a major upgrade and provide better feedback to you.

     

    Scott

  2. Ooops. Sorry for the noise! I've been using a conf file for so long now I totally forgot when I wanted to _not_ use one on a new machine that you didn't actually have to. My bad!

    Scott

     

    Edit: wait...but without using a custom btsync.conf, is there any way to tell btsync where to store the rest of the sync data?

  3. I also got bit by this bug. For me the '*.Conflict.Conflict' or '*.Conflict1' '*.Conflict2' folders were empty, so I had to find and delete those, then rename the '*.Conflict' folders to remove the '.Conflict' extension. It seemed to be _mostly_ all directories that were affected, not files. I used (Linux):

    find . -type d -name '*.Conflict.Conflict' -exec rm -r '{}' \;
    find . -type d -name '*.Conflict' -exec rename 's/\.Conflict$//' '{}' \;

    CAUTION: notice the 'rm -r' in the first command....make sure those directories are empty first!! Run the commands without the '-exec' part first just to make sure you're finding the correct directories.

     

    The 'rename' command might be called 'perl-rename' depending on your system.

     

    Scott