Search the Community

Showing results for tags 'sync.log'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Resilio Sync
    • Sync General Discussion
    • Sync Troubleshooting
    • Sync for NAS (Network Attached Storage)
    • Sync Stories
    • Developers
    • Feature Requests

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 3 results

  1. I would post these two problems separately, but I think they are related. Some background: I've been using sync for months now and love it. One of the directories I've started syncing recently is my photos folders: 450GB in 66,000+ files between a Windows 7 64-bit machine and my Linux server at home. Problem 1. I noticed that the sync was taking a long time and that the speed was really slow. That's when I noticed that the 300MB sync of current files was creating a lot of .!sync files and not finishing the sync on them. I tried moving the files in question out of the folder, allowing the .!sync files to get deleted, and then trying again, but no luck. I tried stopping and restarting sync on both machines. I tried combinations in various orders of all of the above. No joy. I noticed that my Linux version was still the previous stable version (1.1.82 or whatever), so I upgraded to the most recent 1.2.82. Didn't help. Eventually, I solved the problem by removing the photos folder on both machines and allowing them to reindex. As of yesterday, the problem has reoccurred. I don't want to spend half a day re-indexing the folders every time this happens. All other folders sync with no problems. Problem 2. While investigating the first problem, I inspected the log files on each machine. There were a fair number of errors on the Linux side. I turned on debug logging on the Linux machine. Shortly after that, I noticed that my sync.log file was getting huge. So I removed that switch from the init script and restarted the sync service. The logs continue to be huge. Like 9GB+ for 24 hours of operation. I've been running for less than 30 minutes and my sync.log on the Linux box is over 50MB! The log is quite verbose, and looks to me like it's still running in debug mode. I've searched through the forums, but haven't found anything relevant. Maybe my search terms are wrong? Anyway, apologies if I'm retreading anything, but any help would be much appreciated. I'm sure this is just a config issue.
  2. Hello, I have a 500GB SSD and a 1TB HDD setup in my workstation. There are a few folders (on the HDD) that I have syncing to a NAS for Backup. I am running out of space on my SSD, and I see that I have a sync.log file that is 244.2 GB!!. I can't find anything about this (quickly) in the forum. Can I delete this file? Does it perform the same function as the .archive folders (as a backup)? Can I move it to my HDD, where I have more room? Should I uninstall BTSync (which is installed on my SSD) and reinstall it on my HDD? Thanks for any help!
  3. Hello: Currently using btsync 1.1.48 to sync two servers. excellent piece of software. seems to be working fine, but.. in the sync.log file i see multiple examples of read failures as in this clip: [2013-07-31 22:37:35] ReadFile error: me2-iplog1.txt:0:21137:21137:3 [2013-07-31 23:01:37] ReadFile error: me-item2-sessions.txt:0:170:170:3 [2013-07-31 23:01:37] ReadFile error: session-records.txt:0:12052:12052:3 [2013-07-31 23:01:37] ReadFile error: me2-iplog2.txt:0:12738:12738:3 [2013-08-01 00:01:43] ReadFile error: arf-home-sessions.txt:0:923:923:3 these files are all contained within various websites - and a frequently opened/updated/closed by apache/php. can someone throw light on what, if anything, is going wrong here. syncing seems to be working but i am concerned about error messages on live servers! any help is appreciated. environment: windows svr2003. thank you. tim ecott.