Shaav

Members
  • Content Count

    21
  • Joined

  • Last visited

About Shaav

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  1. I have been struggling for a couple of months now trying to get 4 QNAP NAS drives syncing about 2TB of data, all of which had been pre-loaded. Indexing has been a nightmare and never seemed to move forward. For weeks and weeks. Finally, I found that if I stopped btsync on all but one NAS at a time, it would successfully sync all 2TB in about 12hrs. Note, btsync had to be *stopped* completely (i.e. I would ssh in and run ./btsync.sh stop --- not just paused in the UI. Pausing seems to stop the transfer of files (?) but not the back-and-forth communication about the files and somehow, it
  2. @adam1v Not as far as I am aware... but I'm not necessarily in the the loop either. Just didn't want to leave you completely hanging since there have been no other replies...
  3. +1 Would also be nice if there were two levels --- a default global for all shares and then a share-level IgnoreList that would sync across all devices using the share.
  4. @GreatMarko Thansk for the link; will do that.
  5. @RomanZ It is entirely possible that I mistakenly put it there in the past; I just don't remember. Also, because the documentation isn't entirely clear on that point (something that could maybe be addressed?), I possibly put it in both locations "just to be safe". However, increasing the number of devices/shares certainly makes that less feasible quickly. It would be nice if there were a global IgnoreList and a local IgnoreList BTW... But I realize that's a very linuxy kind of thing to do. It would also be nice if the IgnoreList become a propogated property of the share so that if you edit
  6. @Moe Frankly I'm having enough of a miserable time experimenting around trying to understand the behaviour of this software --- I thought *maybe* it was a simple enough question to get straight, conclusive answer instead of trying to reverse engineer it from observation.
  7. Just want to quickly clarify something... The documentation says the IgnoreList goes in the hidden .sync file; my interpretation is that it means the /share_folder/.sync folder rather than the /run_path/.sync folder. But I have IgnoreLists in both locations and I'm not sure if that's by design, because of upgrades where the location changed, or if it was something that I just mistakenly did at some point in the past. What I kind of *hope* is that you can put a global IgnoreList in /run_path/.sync that applies to *all* folders and then a share-specific IgnoreList in /share_folder/.sync and
  8. I realize this is an issue that people bring up here a lot; I haven't really seen much by way of solutions---seems like a lot of them abandon btsync before it gets resolved. I'm hoping that I have more detail to offer about what happens than others... Situation: 4 QNAP NAS drives syncing about 2.3TB of data; ~700K files. All 4 drives are using the latest 2 version. All the drives currently have ~99% identical content; just differences that have occurred from their use since the problems began. 2 of the drives have been functioning perfectly for about 8 months; the problem came when we tried
  9. @RomanZ I was eventually able to verify that they could talk to each other, FYI. There's just other stuff going on. Topics for other threads.
  10. @RomanZ Will look into trying that. Unfortunately, these are all QNAP NASs that don't have netcat on them. Will need to figure out getting in on there first...
  11. Specifically here, I think it would be a lot more functional if rather than renaming the files the way you do now, is always have the most recent version keep the same file name and then rename the versions such that the highest number is always the oldest. I know that means renaming more files on a regular basis, but it would become much easier to, say, write a script to deal with problems like mine.
  12. @RomanZ Yeah... sadly in the situation I'm in, all the files from one peer were deleted which propogated... I rsynced the files back (including all the .n archives cause... hard to separate them out) and neglected to use -a so all the modification times got updated. So no help there. Thanks for the info though.
  13. @Romanz That is what I mean I did when I said "EVEN when I provide explicit VPN IPs and ports for the peers". Does not work.
  14. When files are changed and archived, .sync/Archive/path/ has multiple versions of the file named: file.n.ext and it appears that the highest "n" is the most recent file. Consider this scenario where the default retention period of 30 days is in effect and the same file (test.txt) is edited on a weekly basis: .syncArchive/path: 2015-06-12 test.4.txt 2015-06-05 test.3.txt 2015-05-29 test.2.txt 2015-05-22 test.1.txt 2015-05-15 test.txt by the time 2015-06-19 rolls around, the 2015-05-15 test.txt will be deleted. What will the name of the new archived file? test.txt? or test.5.txt?
  15. Thanks @RomanZ --- this is kind of an unusual case and I'm using VPN because I don't have direct access to the networks in question (except 1 --- not the one I'm particularly interested in. ). So I don't have any idea what the routers or their configurations are like for 3/4 devices that are syncing. I've been experimenting quite a bit and the peers do not seem to find each other on the VPN. I.e. if I turn off relays/tracking/DHT and just leave searching the LAN, they do not find each other. But more surprising, EVEN when I provide explicit VPN IPs and ports for the peers, they won't find e