EscapeArtist

New Members
  • Content Count

    2
  • Joined

  • Last visited

About EscapeArtist

  • Rank
    New User
  1. Basically, I believe that BitTorrent Sync can never be a valid personal cloud service unless a 100% reliable machine, always on, is linked for every shared file. As a result of not having a reliable "server", I regularly get older file versions as a nasty surprise. If you can't rely 100% on one of your syncing machines always being up, you must check every time you save a file that it is actually syncing somewhere. I feel I have to repeat that: You either must have an EXTREMELY reliable machine that is always on, or you must check every time you change a file to know if it propagated (and remember if there are lots of files which did and which didn't). Otherwise (this is obvious, but I will lay it out anyway): - Three machines, A, B and C are supposed to sync a file, let's call it temp.txt - Machine, B, is supposed to be the "server" (i.e. always on) - B is down for whatever reason, C is typically down, so only A is operational - This "should" never happen, but of course, always will at the worst time possible - A changes temp.txt - A is shut down assuming wrongly that the temp.txt has been synced to B - B is now turned on again - C is turned on and temp.txt is modified there assuming it received the latest version from B - C syncs the mixed version to B - A is turned back on and receives the mixed version from B - A's original mods are lost This has happened to me MANY times. I am looking at creating a droplet at Digital Ocean to try to get something more reliable as a "server", but there doesn't seem any other solution. It seems to me that BitTorrent Sync could "know" that A never synced the file after it was modified. Knowing that A's version of the file is "hot" and needs to be synced, it could warn when receiving the file from B. Any comments?
  2. I have not yet mailed my logs to the help email provided by BitTorrent, so I don't expect a technical reply to this post. However, I'm pretty sure I understand what is happening so I'll see if there is a fix for the obvious first. The situation is that I use a product called CLCL which is a clipboard history manager. I've used it since it first appeared maybe 5 or 10 years ago and never, ever have had a failure or corrupt file. I put the clipboard history files in my bit torrent shared folder and I've lost the regist.dat (file truncated to 0 bytes) three times now. I am certain the problem is that CLCL is truncating the file, but I am just as certain it is truncating the file because of something that BitTorrent Sync is doing to the file (locking it perhaps?). It just happened again when I upgraded from the beta to 2.x. So, I am writing this to know if anyone else is having similar trouble, if there is an inherent incompatibility issue, or if I should go formal and send in the logs.