Disappointed Cat

Members
  • Content Count

    299
  • Joined

  • Last visited

  • Days Won

    5

Posts posted by Disappointed Cat


  1. I have a home server running Linux. All shares are added on linux locally and on two win8 PCs also. The laptop is usually off.

    If I'm working on a web project I open the files with Netbeans from Windows via a Samba share so I can instantly check it in the browser. (The webserver is on the linux peer.) So the win8 client just recieves files in the background, like backup.

    But somehow 3 times a file was synced back overwriting a newer one on the linux peer.

    Just in case it's not clear: All shares are added to a local path and I only work on one peer's files at a time.

    Everything is also available via Samba but not everything is synced with BTSync.


  2. Update

    I found some log entries about all 3 occasions. Sorry, I didn't check before.

    These are logs from a linux peer, where I edited the files via a Samba share.

    The .3 IP belongs to a Win8 client, where these files weren't even opened.


    [20130530 23:42:07.401] Incoming connection from 172.30.20.3:18553
    [20130530 23:46:52.214] 172.30.20.3:49072: did not pick any blocks. blocking peer temporarily
    [20130530 23:46:52.266] ImporterBase.cls.php: Piece 0 complete


    [20130601 03:17:23.134] ReadFile error: CatLab.cls.php:0:22680:22680:3
    [20130601 03:17:24.286] 172.30.20.3:49072: did not pick any blocks. blocking peer temporarily
    [20130601 03:17:24.432] CatLab.cls.php: Piece 0 complete


    [20130601 04:04:17.988] Incoming connection from 172.30.20.3:54037
    [20130601 04:07:28.557] 172.30.20.3:49072: did not pick any blocks. blocking peer temporarily
    [20130601 04:07:28.610] CatLab.cls.php: Piece 0 complete

    Also there are hundres of lines like these but they are way earlier, going back days..


    [20130530 18:33:11.011] Failed read from file error = 9
    [20130530 18:33:11.011] File changed during hashing


  3. It happened with files I was editing in Netbeans.

    I was often saving the second time before it was even synced and maybe it confused the client somehow.

    Or maybe Netbeans' code scanner (for auto completion, etc) locked the file and that caused some problems.

    This only happened 3 times in a few hours so I don't know what really caused this.

    What I do know is that I worked on projects before and earlier versions didn't have this problem, or I was very lucky.

    Maybe there should be a limit on how often can a file be synced. Say once in 2 minutes.

    I'm guessing this would eliminate these kind of conflicts and also reduce the over syncing.


  4. It seems the android app causes other peers to touch (unix touch) directories that are partially synced. In other words every time I start the droid app, the (c|m)time of directories that contain synced files (on the phone) changes on my linux server.

    This confuses the heck out of my backup scripts..

    Edit: This seems to be an isolated issue or not directly related to BTSync. ^^


  5. I dug up my old My Audio tablet (4.0) and it crashed before I could even install the app.

    Anyway after dealing with the same old shit, BTSync installed and works without a problem.

    I also tested the mobil-to-mobil feature. Works seamlessly.

    I can't wait for this to be widely used.


  6. I tried it out too. It works fine on rooted HTC Desire, Android 4.2, CyanogenMOD.

    It didn't require root however.

    My first impressions:

    * I like the UI and the QR code approach.

    * The folder view needs alphabetical ordering - it's chaotic now.

    * I also like the on-demand solution but I have a different idea how it should work.

    * Cellular data should be a per share setting.

    I think there should be only one file browser in which the user can select which files should be always offline via long pressing or something. This also should work with complete folders, that almost no other programs support. By simply opening something it should be temporarly synced. Also creating the entire directory structure makes things inconvenient.

    Keep up the good work. :)


  7. I'd use a simple bash script to manage all kind of trashes.

    Here's mine:


    #!/bin/bash
    trashes="/mnt/Volume/.Trash*/
    /mnt/Volume/.Dropbox/.dropbox.cache/*
    /mnt/Volume/*/.SyncTrash/"

    case "$1" in
    rm)
    for dir in $trashes; do
    if [ -d "$dir" ]; then
    rm -rf "$dir"
    fi
    done
    ;;
    gc)
    for dir in $trashes; do
    if [ -d "$dir" ]; then
    find "$dir" -depth -type f -ctime +7 -exec rm -rf "{}" \;
    find "$dir" -depth -type d -empty -exec rmdir "{}" \;
    fi
    done
    ;;
    ls)
    for dir in $trashes; do
    if [ -d "$dir" ]; then
    find "$dir" -type f -printf "[%Cm.%Cd %CH:%CM] %p\n"
    fi
    done
    ;;
    *)
    echo "Usage: $0 {rm|gc|ls}"
    exit 1
    esac
    exit 0

    You can set up "/path/to/script gc" as a daily cronjob and it deletes files that have been trashed 7 days ago.


  8. Great news!

    I noticed the metacache directory is not deleted automatically. Can we get rid of it?

    My music library will be re-indexing many-many hours and it still blocks every other share that comes after it in configuration order. I think indexing should run in two threads - one thread for one share at a time.

    It seems the DHT floods (when it's disabled) are gone. Thanks.

    And great job on the optimization. :)


  9. Problem solved :)

    Really?

    Please show us a way to wire it together with BTSync without the risk of exposing the key of the original data. :)

    Should I create a virtualized system with an OS that even encrypts the RAM?

    Implementing it in the client is a good idea indeed, but keep in mind that this shuts out Windows [8] as a host.

    I could settle for a Unix-only encrypted nodes feature nevertheless.


  10. The webUI is rather rudimentary and it's low priority as it should be in this early stage.

    If you really want to reorder the shares (like me) then use a bencode editor and reorder the blocks in sync.dat.

    At the next start, the file guard hash will be wrong but it won't cause problems

    except there's gonna be a sync.[number].bad copy of the file which you can delete.

    PS: When you edit any config files, always stop the client.


  11. There are a couple of problems with EncFS (and ecryptfs):

    - It's horribly slow.

    - Dokan does not work on Win8 which is a dependency.

    - On Unix systems if you also want file permissions and ACLs you have to give up even more performance.

    And for last: BTSyc would waste resources to re-encrypt everything for transfers.

    If there won't be official encrypted nodes feature someone will probably figure something out

    and implement it using the API.