Shot2

Members
  • Posts

    27
  • Joined

  • Last visited

Posts posted by Shot2

  1. BTSync 1.2.73 under vanilla Ubuntu 13.10 x64 Server, still no luck enabling logging.

     

    Tried so far:

    • adding "--log file" to daemon args in /etc/default/btsync
    • adding "--log file" in the /etc/init.d/btsync initscript (ain't that old-fashioned, btw?)
    • both solutions above experimented with and without a 'debug.txt' file (containing variously '0' '1' 'ffff' 'omgwtfbbq') in BTSync's storage path.

    To no avail.

     

    Will gladly send logs if it helps debugging. Oh, wait...

  2. Where are you running your btsync executable from?

     

     

     

     

    Not really, since files and directories that start with a period are hidden by default in ALL linux distros.

     

    ls -la in the directory you run sync from.

     

    Under Ubuntu find returns hidden files too ;) try it for yourself, it works. Still, can't find a .sync directory anywhere on the server.

     

    Also, the only btsync executable is a daemon located at /usr/lib/btsync/, yet no .sync dir in there.

    ls -al /usr/lib/btsync/total 3356drwxr-xr-x  2 root root    4096 Oct 27 04:16 .drwxr-xr-x 59 root root    4096 Oct 27 04:16 ..-rwxr-xr-x  1 root root 3424952 Sep 20 12:50 btsync-daemon

    The daemon runs under a system user, whose homedir has no .sync subdirectory - only a bunch of files (settings.dat etc. + databases corresponding to loaded secrets). Still can't figure where the webUI stores the new password, and whether it's possible - not to say advisable - to redact the older one in <btsyncinstance>.conf...

  3. the .sync directory off of where you run the executable from

    sudo find / -type d -iname ".sync"

    returns no results for BTSync latest under Ubuntu. Weird. Something fishy.

     

    I naively thought the webUI params were where I wrote them (e.g. in /etc/btsync/myuser.conf) but having changed the password in the webUI, that is indeed not reflected in that latter file.

     

    On to my question: now that the WebUI has stored its settings in some undisclosed/unreadable location, is it ok to remove the {webui} section (or perhaps more specifically, the plaintext login/pass info) from that myuser.conf? :)

  4. Months go by and still no luck. Still stuck with this dumb "/gui/" (talk of a non-informative url...)

     

    At least, please consider providing a configuration option for that base directory (e.g. in the .conf file, under the webui section), something along these lines:

    "webui" :        {                "listen" : "127.0.0.1:8888",                "login" : "username",                "password" : "userpassword",                "basedir" : "btsyncGUI"        }

    so that the webui becomes accessible (and reverse-proxyable) at "http://127.0.0.1:8888/btsyncGUI/"

     

    Shouldn't be rocket science...

  5. Is a read only child client involved in the syncing process of other child clients...meaning: if I have a "server" machine that many read only machines are synced with, do the read only machines aide in the sync to help reduce load on the server?

    If so, how is this affected by issues described else where, for example, if one of the read only clients edits the document?

     

    Same question. To me it's not perfectly clear: after experimenting, it seems in a "one master (r/w) - many clients (r-o)" scenario the clients do not exchange data between them.

     

    Example:

    I add one "NEW" file to the "master". It starts getting distributed to a few online "clients", who eventually get the whole file.

    Now I take the "master" offline, for a few days.

    Now a few "clients" come and are added to the swarm. They won't get the "NEW" file from existing "clients", not until I switch the "master" back online.

    Either there's something fishy in that definition of a swarm, or there's a bug which prevents r-o clients to contribute data between them...

     

    (tested Ubuntu x64 1.1.70)

  6. Same error messages here (v1.1.69 Win or v1.1.48 Ubuntu "master" side, v1.1.48 client side). Syncing to that client has been stuck for days now (no progression), I get hundreds of thousands of such errors for 10s of thousands of files:

    Torrent Archive.zip status:137 error:<NULL> meta:1 conns:1 io:0

    More worrying: for these thousands of files, it uploads something to the client (a few KB), then transfer speeds drop to zero. After a few hours/days, the same files reoccur with same issues and symptoms. Today only, it has uploaded ~3GB of data but to no avail... Wash, rinse, repeat. Nothing changes. The debug log file is now at ~500MB.

    Even if purportedly a "status message", it would be nice to have some actual reason for this mess... I know developers of closed-source software like to obfuscate the inner workings of their babies, but it could actually help to know the meaning of that cryptic "status:137 error:<NULL>".

  7. Please search the forum for "nested" shares.

    ...the bottom line is that you can't separately sync a sub folder if you're already syncing its parent

    Not possible with BTSync. Prioritization of inherited permissions in a hierarchy tree is no issue at all for other software and a variety of uses. Sure, takes a different kind of hierarchical processing but it's no definite theoretical impossibility - only a design choice in BTSync.

  8. .sync is the default path for storing Sync data. It can be changed with storage_path parameter in config file. You need to create debug.txt file in your storage folder. If you put 0 in debug.txt, it will disable logging errors. If you put FFFF there, it will enable all debug logging.

    OK, got it. Found the ID, IP and version (1.1.42) of the read-only peer which has retained now-deleted files. Weird. Will ban it and disable logging, thx :)

  9. As said, there is no way to contact this peer (or better said: I have no idea who to contact).

    Also,

    Linux: create file debug.txt with contents of FFFF in the .sync folder. You can find the .sync folder in the same directory where the btsync binary is located.

    there is no ".sync" directory, nowhere on the server, zero, nada.

    The biggest issue at the moment is the logging of the same error every 10-12 seconds for several weeks now. Any way to disable any and all log messages? Or is there any way to block bad peers, peers gone mad etc.? (I'd do it with a simple firewall rule if BTsync was able to detect and display peers' IPs rather than their 'names') I really don't want to delete that secret (used by dozens of peers) only because of one remote peer acting crazy...

  10. Hi,

    BTSync 1.1.42 running on Ubuntu 12.04.2 Server. One folder shared, successfully indexed in full, with 3 clients using a read-only secret (no idea about which version they use)

    Looking at my sync.log file, there is this error message repeating every 10-15 seconds... for days now:

    [20130619 19:45:25.314] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

    [20130619 19:45:37.559] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

    [20130619 19:45:48.786] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

    [20130619 19:46:00.386] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

    [20130619 19:46:24.170] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

    [20130619 19:46:36.677] Merge: failed to verify signature of remote file reseller/OT_2012.iso.7z, aborting

    The thing is, this ~200MB file has been removed from my side, but if I interpret correctly that small error message, it's probably still present at some remote peer(s). No idea which ones, actually, the message does not provide any clue. Still I guess it's at that peer which appears in a "stuck" state for weeks now (= with everything to redownload, yet nothing moves).

    How to solve such a situation? I have no immediate access to/contact with the relevant remote peer(s)...

  11. I'm just curious what hosting options people have found to do this? The best I have been able to find is a dedicated server from Hetzner (2x3tb HDD) or a "Kimsufi" from OVH (500gb HDD).

    The Hetzner would be ideal, but is a bit of overkill (Core i7 + 16gb RAM) when I really just want the disk space, but I think I'd outgrow 500gb from OVH pretty quick.

    Has anyone found a provider offering boatloads of disk on a low-spec machine?

    What's wrong with the Kimsufi 2G plan? Double the specs (i.e. 1TB, 2-core CPU), for a few bucks more. And everything works on their servers, unlike other providers with uncanny setups... For larger storage needs, you could easily use any other *serious* cyberlocker as a means to expand storage (any "backup" plan should allow it, provided you encrypt everything so the company has no peek at your usage)

  12. Wish: a way to force peers to upgrade their clients / recreate the share. With its rapid development, btsync has seen numerous changes and improvements (hopefully) which may cause incompatibilities between outdated and more recent versions. So far, it seems clients simply fail connecting to a new up-to-date "master" share. I also guess it might explain why peers appear in a "stuck" state sometimes - incompatible versions, or their local btsync db being somehow corrupt.

    Not sure if secrets and peer connections transmit some version information that could be put to use in order to warn (and potentially mitigate) conflicts.

    Not sure either if they get any notice about version inconsistencies, but it would be nice if when adding/connecting to a secret they'd get a useful message e.g. "The secret was added, however it may not work as expected. To fix it, please consider upgrading your BTsync software. Alternatively, you could try deleting then re-adding that secret, pointing to the same folder." Or something along these lines.

    Would save time by encouraging "in the background" people to update / fix issues, rather than peers having to contact each other by mail, snailmail, phone "hey dude, your sync client is stuck, u should update blaah blah blah"

  13. Hmm...I actually like this change, but maybe it is because of what I'm using the software for. I like the old version being synced across all of my clients because if I make a bad change, I can recover it for any client. The change is simply integrating the trash and the archiving together into a single thing (which they basically are). I don't see how a (dot) at the beginning of the file makes a difference, because it is simply a UI thing (the shell hides the file for you) and not a functional thing. I do think it would be nice to disable trash/versioning and I think it is possible by setting the sync_trash_ttl to 0.

    It makes a difference because the .Sync[Whatever] file or dir is no longer 1/ hidden 2/ interpreted as a special file by other software accessing the directory tree, e.g. a web server. Makes maintaining a server needlessly more complicated - having to define special rules for these BTsync-proprietary files. Image people downloading up-to-date files via, let's say, FTP or HTTP, they will stumble upon that "SyncArchive" dir and grab it for nothing (either because it's empty, or because it contains gigabytes of deprecated/outdated/buggy/temporary files). It's no definitive deal breaker, but it's imho a weird and rather unflexible design decision.

    Worse: just found that upon restarting btsync, and even though all shared folders are explicitely configured as "Do not use the Sync trash", that damn (and explicitely configured as "do not use, you're useless, keep away of my hierarchy!") folder gets recreated... So now we have to reconfigure servers to forcibly hide/do not serve a new filename (until the next change by btsync devs) + run a cron task to forcibly delete Sync[Whatever] folders :)

  14. I don't think this was a good idea. At least for me this is very inconvenient.

    Please rename it to .SyncArchive or give the option to do so.

    Also .SynTrash folders remained as they were and now we have to manually rename them everywhere.

    +1, this is a terribad idea. Especially now that it is no longer hidden by default under Nux. At least there should be a way to customize the location for "trash", and/or disable it altogether.

    The cleanest way would be NOT to mix app-specific metadata and trash/outdated files within live, current, potentially publicly-exposed data. A centralized DB (in %APPDATA% under Win, under /usr or e.g. user .config dir for GNU Linux) would be the way to go.

    (Sticking with 1.1.33 for the time being until it gets eventually fixed.)

  15. 34ynzo7.png

    Issue still there with 1.1.33 under Win. I uninstalled 1.1.30 Win, removing settings, and recreated the folder share. All files are there on both sides, correctly synchronized (i.e. with the Ubuntu 1.1.30 server) but the Win client is still stuck as if there was everything to upload. Half an hour later, nothing changed.

  16. Same issue here, between Win (BTsync v1.1.27) and Ubuntu (BTsync v1.1.30). Both sides have the exact same set of files, but both sides show the must reupload the same set of files to the other side.

    Illustrative screenshots, both sides (WebUI Ubuntu & Client software Win):

    • 2m2gn4y.png
    • 20qkoi8.png

    Nothing happens since 20 minutes ago... restarted both sides, in both orders (A/B or B/A), no change.

    Can't send logs now, as it includes a lot of personal info I have to expunge.