Osiris

Members
  • Posts

    29
  • Joined

  • Last visited

Posts posted by Osiris

  1. I must concur with dgl289.

    No http proxy is sad, since it's the only way to proxy over here.

    Allthough ... when I set it to https, I am able to connect to the update site (which otherwise is blocked or gives a timeout, both without proxy as with the socks proxies).

    Whatever I try, I cannot get it to work. I've added a predefined host, I've tried all forms of the proxy.

     

    Should I check whether our proxy supports http connect ?

     

    UPDATE : in response to florentm:

    Using proxifier & my ssh tunnel, I'm able to route all btsync traffic through the tunnel, making the sync function.

    I've added a proxification rule for the btsync.exe app to any host on any port throught the http proxy on port 8080 (which is our corporate proxy).

  2. Hi,

    Since the (manual) update to 1.4.72 on my qnap I have a strange issue where I cannot click the share or edit buttons on existing sync-folders.

    The buttons actually appear on the header bar when I hover over the sync folder.

    When I move to the header bar to click the buttons, they disappear again (since I'm not hovering over the folder).

    What can I do ?

     

    post-25944-0-93018900-1409131414_thumb.j


    UPDATE : This only occurs in the latest Firefox.

    In Chrome & IE it works fine.

  3. Update. Still syncing. Less than a terrabyte to go.

     

    Where can I find info on the whole syncing process ? Can't seem to find it in the docs.

     

    It seems some .!sync files are still being created on my read-only destinations.

    I assume these files are to be considered in progress.

     

    Yesterday, there were different ones on my destination but also 1 on my source.

    This is weird since there's no two way syncing being done.

    I'm assuming that syncing of the (large) file started while the file was being copied to the system and the .!sync file was then created somehow.

    I'm going to prudently conclude that this one file was the only problem.

  4. You cannot begin to imagine how much this has helped me.

    I ran this on both machines

    find /mnt/raid6/video/ -name "*.\!sync" -exec rm {} \;

    and restarted the btsync processes.

    Syncing resumed.

     

    a massive +1, if u ask me.

     

    I'm talking about a sync between a freebsd (Freenas 9) and my qnap.

    Had to run the line on a mapped drive from my ubuntu server to the qnap nas, since their find command doesn't allow the -exec.

    So In my opinion, case sensitivity has nothing to do with it.

     

    It also means that everything I said before was wrong or insignificant. Hurrah !

  5. Go all open security-wise on file level & see what gives ...

    Adapt accordingly & give full access to 'others' on files for both btsync program as synced folder (& all files & folders below).

    chmod -R 777 /mnt/raid6/programs/btsync/chmod -R 777 /mnt/raid6/btsynced

    Also, go all open in samba/cifs -> creation masks 0777 or 2777

     

    If you see a sudden boost in sync speed, this will show I was right on a few previous accounts.

    It's a rights problem.

     

    Do me a favor. Post the owners of your synced files as well as your .SyncBlabla folders/files.

    Is your btsync user 'btsync' the owner of the .Sync... folders/files ?

    Perhaps adapt this as well with a chown btsync:nogroup (or the right group) on the .Sync folders/files.

     

    Do this for linux & android ...

  6. It's possible that the files your removed were removed whilst still transferring data, and therefore Sync is still waiting for them to complete (which they never will if the source files have been deleted)

     

    So, with Sync not running on any of your devices, check for and remove any .SyncPart, .SyncTemp and .!Sync files, then restart Sync.

     

    If that fails to resolve the issue, I'd suggest you remove the folders from Sync on both devices, and then add them back to Sync - this will cause a re-index of the folders.

     

    If this would describe btsync's actual behaviour, I'm considering this a major bug.

  7. Adding/changing files or folders in a btsynced folder causes a silent reindex, it seems.

    The larger the folder, the more the effect.

    When talking about larger folders of +500GB, the btsync app seems like it's doing nothing at  all in the webui. After some time, it will continue with the actual file transfers.

    For large, synced folder in which files are often changed or added, btsync is missing its effect, imho.

     

    When on a rather weak cpu, like the one in most NAS'es, this will cause a full load on the cpu for a long time.

     

    Question 1:

    Am I stating this behaviour correctly ? Is anyone else experiencing this ?

     

    Question 2:

    Could this re-scan be at least visualised somehow in the webui ?

     

     

  8. Same issue on 3 syncing linux machines : Freenas server, QNAP TS-412, Ubuntu server 13.04

    I'm syncing my video files via bittorrent sync. About 6TB.

    I think I actually fixed the issue, but still not sure. Syncing is slow and uses 3-5 % of network capacity.

     

    What helps is splitting up the folders in different sync entries in the webui.

     

    I had to run this line on my Freenas (which is the main server, the others do read-only sync):

    find /mnt/raid6/video/ -name ".Sync*" -exec chown btsync:nogroup {} \;

    ... since somehow I had done a chown nobody:nogroup on everything.

    The btsync user could no longer access the .Sync* folders and files, but no warning is given UNLESS you have ZERO files already synced in that folder. Yes you better read that again :-)

     

    If zero files and folders are synced and btsync is trying to index, you get the warning (in even worse English than mine) :

    "Don't have permissions to write to the selected folder."