sandymac

Members
  • Posts

    20
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by sandymac

  1. The web UI for selective sync is decent but has one quirk I'd appreciate cleaned up.  If a deep subfolder is set to sync, you cannot later mark the parent folder to start syncing without removing all subfolders that are currently syncing.

     

    eg: If I have a share with this folder tree with joined as selective sync:

    Foo/ +-Bar/ +-Baz/

    If I decide to set Bar to sync that folder will start to sync as desired. (good so far)

    Later if I decide I want Foo to sync I have no UI controls to start syncing it unless I find Bar and pick "remove from this device", exit the sync picker UI, and open the sync picker UI again.

     

    The above can be a negative if Bar contains large files and the above process results in deleting those files only to re-sync them shortly thereafter.

     

    Ultimately, the sync picker UI I'd like is similar to what CrashPlan has with a tree view and check boxes that let me navigate a tree quickly and set the include points and uncheck any exclude points.

    Rename_Drive_App.png?revision=1

  2. Coming up on two years later and this is still a bug for me for btsync 2.3.0 on Linux x86.

     

    Bug (note GUID cookie):

    $ curl --verbose --cookie GUID=a http://localhost:9999/*   Trying ::1...* connect to ::1 port 9999 failed: Connection refused*   Trying 127.0.0.1...* Connected to localhost (127.0.0.1) port 9999 (#0)> GET / HTTP/1.1> Host: localhost:9999> User-Agent: curl/7.43.0> Accept: */*> Cookie: GUID=a> < HTTP/1.1 400 ERROR< Connection: keep-alive< Content-Length: 17< Content-Type: text/html< * Connection #0 to host localhost left intactinvalid request

    Works (note cookie name change):

    $ curl --verbose --cookie GUIDx=a http://localhost:9999/*   Trying ::1...* connect to ::1 port 9999 failed: Connection refused*   Trying 127.0.0.1...* Connected to localhost (127.0.0.1) port 9999 (#0)> GET / HTTP/1.1> Host: localhost:9999> User-Agent: curl/7.43.0> Accept: */*> Cookie: GUIDx=a> < HTTP/1.1 301 Moved Permanently< Connection: close< Location: /gui/< * Closing connection 0
  3. Why should I trust link.getsync.com? It's not that I don't trust the developers at BitTorrent Inc, I wouldn't use their app if I didn't. What makes me nervous is that the HTTPD access_log is going to be a sliding window database to access shares if your servers ever get hacked or you're served with a NSL.

    If the https://link.getsync.com/?f=... used a hash '#' instead of question mark '?' e.g.: https://link.getsync.com/#f=... then the private parts would not be transmitted to your server and it's logs.

  4. I've used BitTorrent Sync on a QNap TS-269 Pro via Qnap provided packages. This is an Intel Atom based NAS.

     

    Sometimes, I've replaced the btsync binary with a newer one if Qnap hasn't updated it's package in a while. Just copy it over the previous one and restart the service.

     

    Also, I've added "umask 000" to the Qnap provided btsync.sh init script otherwise files synced by btsync will only be writeable by the admin (root) user. This probably would be useful on all Qnap devices.

  5. Previously I was asked me to wait for until an update to the web UI about a bug I was having with cookies. With 1.3.105 the problem is still there. I've boiled the problem down to the smallest test case I can. Basicly if there is a cookie with a name that ends with "GUID" the HTTP request for the web UI errors with "invalid request" for me. Doesn't matter what the cookie value is.

     

    Test script:

     

    #/bin/bash

    cookie="xUID=a" # no error
    cookie="GUIx=a" # no error
    cookie="GUIDx=a" # no error
    cookie="GUID=a" # invalid
    cookie="xGUID=a" # invalid
     
    curl --verbose --cookie "$cookie" "http://localhost:8888/"

     

     
    Sample output:
    $ curl --verbose --cookie GUID=a http://localhost:8888/
    * Hostname was NOT found in DNS cache
    *   Trying ::1...
    * connect to ::1 port 8888 failed: Connection refused
    *   Trying 127.0.0.1...
    * Connected to localhost (127.0.0.1) port 8888 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.35.0
    > Host: localhost:8888
    > Accept: */*
    > Cookie: GUID=a
    < HTTP/1.1 400 ERROR
    < Connection: keep-alive
    < Content-Length: 17
    < Content-Type: text/html
     
    * Connection #0 to host localhost left intact
    invalid request
     
    Repeat of this post.
  6. Thoughts on new Web UI:

    • the CPU impact to update the page is much better. On my slow laptop I can pull up the btsync web ui for my host with over 1500 shared folders and not grind the laptop to a halt.
    • Showing only the last part (basename) of the shared folder path obscures lots of useful information to me. I would greatly appreciate a path collapsing UI sort of like I've first seen with usenet folder paths: eg "alt.example.group.foo" might show up as "a.e.group.foo" so "/path/to/data/files" might show as "/p/t/data/files" based on approximate column width.
    • Filters to show only shares with connected devices and shares that have active transfers would be appreciated.
    • Sort by name, size, pending transfer amount would be nice.
    • I'd prefer the down/up transfer rate at the top of the page.
  7. Previously you, RomanZ, asked me to wait for a future version until the web UI was updated about a bug I was having with cookies. The problem is still there. I've boiled the problem down to the smallest test case I can. Basicly if there is a cookie with a name that ends with "GUID" the HTTP request for the web UI errors with "invalid request" for me. Doesn't matter what the cookie value is.

     

    #/bin/bash

    cookie="xUID=a" # no error
    cookie="GUIx=a" # no error
    cookie="GUIDx=a" # no error
    cookie="GUID=a" # invalid
    cookie="xGUID=a" # invalid
     
    curl --verbose --cookie "$cookie" "http://localhost:8888/"

     

     
    example:
    $ curl --verbose --cookie GUID=a http://localhost:8888/
    * Hostname was NOT found in DNS cache
    *   Trying ::1...
    * connect to ::1 port 8888 failed: Connection refused
    *   Trying 127.0.0.1...
    * Connected to localhost (127.0.0.1) port 8888 (#0)
    > GET / HTTP/1.1
    > User-Agent: curl/7.35.0
    > Host: localhost:8888
    > Accept: */*
    > Cookie: GUID=a
    < HTTP/1.1 400 ERROR
    < Connection: keep-alive
    < Content-Length: 17
    < Content-Type: text/html
     
    * Connection #0 to host localhost left intact
    invalid request
     
    Also, updated my Gentoo overlay https://github.com/sandymac/gentoo-overlay
  8. Just FYI incase it happens to you. On my linux box, btsync got stuck at startup because while running it opens a sqlite db for every shared folder and sqlite maintains two extra lock files per db file while open. With the default nofile limit (max number of open files) at 1024 this means as you run out of file handles at about 340 shares because of sqlite database files.  On linux you can boost this limit by editing /etc/security/limits.conf .