hawibtsync

Members
  • Posts

    60
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by hawibtsync

  1. Ok, I found it. I had to compare every device combination individually with my "TotalCommander Sync Directory feature" to find the differences. In 100% it was a case mismatch. I found something like that on one of the Linux i386 boxes:

    A document.pdfA Document.pdf

    I could reproduce it as well. You need a mix of different OS platforms to catch that problem:

     

    * On a Windows box create a file like the first one above "A document.pdf"

     

    Now the other devices start to sync this file. Rename that file to e.g. "A Document.pdf". It is very important to do this while some devices did sync already but a slower device is in the middle of that operation.

     

     

    There are two possible results:

     

    * On one of the devices you see a *!sync* file. Means something has been broken. The status within the BTSync GUI will show a device with pending transfer volumes (it will never complete).

     

    * You see both files ("A document.pdf" and "A Document.pdf") on one of the devices that has a case sensitive filesystem.

     

    You won't see this problem if you wait for all devices to complete the first sync and rename later.

  2. Windows 8.1 with 1.1.82

    Android with 1.1.33

    Linux i386 with 1.1.82

     

    On my Galaxy Nexus with only 8GB I don't sync shared folders automatically. I only select files individually and they become downloaded.

     

    For example. I have a big library (shared folder) with newspapers. This folder is not synced automatically. So to read a newspaper I click on it, it becomes downloaded, I read it and I delete it from the Android device after I'm thru with that document. This last step forces this file to become deleted on all other devices.

     

    My wife has that same document on her device as well. So if someone has read that document it becomes delete on the other device. For me that's a standard use case.

     

    Is it a feature? If yes, how to delete files I no longer want on the device?

     

    Is it a bug? Don't know. But I think there's something missing ...

  3. Thanks for your answer.

     

    99,99999% of all folder/file creation/update/delete is done on one of my Windows machines. This is replicated to the other devices (some have all shares, some only few). So I doubt that permissions might produce problems here.

     

    However, I don't have root access to the four Android devices. All stock Android (Galaxy Nexus, etc.). I did install the APK and that's all. Configuration was done with the help of the BTSync settings. No manual interaction here.

     

    The two Linux machines are the only ones where permissions might come into the game. But these are unRAID servers (that's a special Slackware distribution created by www.lime-technology.com). Again, i don't use command line here. btsync is a package for this distribution. I did install that package and configured it with the BTSync settings.

     

    I checked some things on the Linux machines. User is "nobody:users". The btsync process is running under that same user:

    nobody    2615     1  3 13:59 ?        00:04:28 /usr/local/btsync/btsync --config /mnt/cache/.btsync/btsync.conf

    I do see some permission differences but in all cases nobody is the owner:

     

     

    519156  909 -rw-r--r--  1 nobody users  927851 2005-11-27 10:12 PICT1003.JPG519141 1161 -rwxr-xr-x  1 nobody users 1186485 2005-11-27 10:13 PICT1004.JPG

    I don't understand it...

  4. I saw similar messages here in this forum but I would like to help you to track that down. Why do several of my shares show differences? How to find those differences and how to get a better feeling that BTSync is working correct ;-)

     

     

    General

    =======

     

    2x Windows 8.1, all on version 1.1.82

    4x Android (3 different device types, 3 different versions), all on version 1.1.33

    2x Linux i386, all on version 1.1.82

     

    All these devices are working in my own LAN, no WAN connection.

     

    I painfully avoid foreign characters in all my folders.

     

     

    State

    ====

     

    1x share shows 2.9 MB difference with an upload arrow (from Windows&Linux to Android)

    1x share shows 8.0 MB difference with an upload arrow (from Windows&Linux to Android)

    1x share shows 46.9 MB difference with an upload arrow (from Linux to Windows)

     

    These differences didn't go away in a month now.

     

    Time difference according to sync.log -8.

     

    Debug is switched on (> 100MB). in this sync.log file I can't find any hints why there are differences.

     

    I did compare all devices with TotalCommanders Sync-Directories-Feature. The result:

     

    * The first two shares shown above (Windows&Linux to Android) are in sync (but don't show so).

    * The third share shown above (Linux to Windows) is different (but not on 46.9 MB).

     

     

    Help needed

    ==========

     

    Currently I don't trust the BTSync because of the differences I see. So, once a week I use the TotalCommander sync-tool to compare all directories on all devices and there's always something I have to fix. Sometimes I need to remove a file on all devices and to re-copy it back, sometimes I simply copy a missing file, lots of times there are *!sync* files to remove, and and and ...

     

    So what can I do to help you to fix these errors. A full blown DEBUG sync.log is sitting here. Any interest?

     

    Thanks in advance.

     

  5. Thanks for your answer.

    No reboot. This Windows 8 machine is running 24/7.

    Whenever I realize that this machines harddrive is spinning like crazy I look into the Folders tab of BTSync and see that one of the folders is re-indexing then. To get back to normal operation I have to kill BTSync. After BTSyncs restart re-indexing takes place - this is ok and tolerable. But after some time re-indexing starts again and again and again...

  6. Following environment:

    2x Windows 8 PCs with 1.1.42

    2x Linux Slackware PCs with 1.1.42

    2x Android Devices with 1.1.19

    The Android devices are:

    1x Galaxy Nexus 4.2.2 Stock-ROM, not rootet

    1x Magic Cube U9GT2 4.0.3 Custom-ROM, rootet

    NTP for all 4 PCs via Router, the two Android devices get their time via WLAN. Thus time is identical for all.

    The problem:

    After an initial sync of all machines/devices, whenever I change something on the four PCs it becomes synced to all other machines and after that it is overwritten from one of the two Android Devices with the old copy.

    I even did delete a file on a PC, did wait for the sync, and did copy this file back. It was overwritten with an old copy (don't know where the devices did get the old copy from).

    Is there a Debug Mode for the Android Devices?

  7. This must be an issue with your connection then.

    This is LAN only.The Windows 8 and i386 machines worked nearly perfect.

    Do you by any chance use a rooted Android device? My Galaxy Nexus is stock Google, so no additional permissions on file systems etc..

    All files written by BTSync get a new timestamp on the Android Device - not the original one. What timestamps do your files get on the Android device?

  8. Ok, after a day with BTSync for Android I think I found the reason for the bug mentioned above. I still think it's a bug and I think it has to do with files copied to the Android device don't receiving the original timestamp.

    The scenario:

    * 1x Windows 8

    * 2x i386

    * 1x Windows 8 (offline)

    * 1x Galaxy Nexus (stock Android 4.2.2)

    All four machines were synced before installing APK on Android.

    Please have a look at the History shown in the attachment:

    * The APK was installed (the APK file was synced in my network)

    * I created all shared folders on the Android device and linked them with the QR codes from the Windows 8 machine.

    * On the Remote tab in the Android app I touched all files in the "KeePass" folder, the file starting with 13 and all files in the Bittorrent folder.

    * All these files were synced successfully from my network to the Android Device and received the green marker in the app.

    * Some minutes later all files were synced back from the Android Device to my network (Galaxy Nexus added file ...).

    Now it get's weird: These files did have the current timestamp from the Android Device and overwrote the correct files in my network. Bouncing starts now. The files were synced again this time with the new (wrong) timestamp and this process never ended until I did de-install the APK from my Android device.

    post-24616-0-12386500-1371653111_thumb.p

  9. I did create an empty folder on my Android 4.2.2 (Galaxy Nexus) Device. Added that folder to BTSync Mobile and attached the QR code from the monitor. The shared folder is a music folder with 200 tracks.

    After that I opened this shared folder in the app, switched to the Remote tab and touched all 200 files one after each other (without waiting to complete).

    Immediately after that all 200 files on all desktop computers (2x Windows 8, 2x Linux i386) get renamed to *.sync! and become overwritten from the Android device.

    The folder on the Android device was empty and is filling currently. With every file this file copies back to all other PCS ...

    Regards

  10. Sorry for buttin' in but I just came here to report a bug because sync does not start automatically and I do need to click every file to start one individual copy process.

    So you say I need to click on all individual 200 music files in the shared folder to get them 'copied'? That's no sync, isn't it?

    My dream was to sync my 10,000 images to my in-house-tab with just one single click ...

    * Galaxy Nexus with Android 4.2.2

    * Magic Cube U9GT-2 with Android 4.0.3

  11. The Linux i386 build (BitTorrent Sync 1.1.12) segfaults on my in 32bit ubuntu 13.04 machine.

    Linux i386 doesn't work here. It starts, reports the following lines to it's log file and dies without any further information:


    [20130512 19:29:52.041] Loading config file version 1.0.134
    [20130512 19:29:52.661] Loaded folder /mnt/disk1/Private/BTSync/Pics

    The previous releases did work.

  12. Copy operation means, that first you remove the original file, then you create a new one with the same content. It will have a different timestamp that is set by OS (nothing to do with Sync) and Sync will detect that content is similar just changed timestamp, so this information will be propagated to all nodes. I don't see any problem here, or I just don't understand what you are tying to say.

    Must be my bad english.I do overwrite an existing file.

    The new file has the same content as the overwritten file but has a new timestamp. This operation is not propagated to the other nodes. The file on the other nodes is untouched and keeps the old timestamp. The history does not show those files. BTSync behaves as if there's no change at all. I can reproduce that at will on Windows 8.

    EDIT: Added a file listing from my Windows 8 (the source) and one of my Linux Slackware machines. All machines use release 134. All files where produced at the same time at the same time. Files with unchanged content are not synced and keep their old timestamp:


    C:\Privat\BTSync\Daten\unRAID\Dump>dir
    Datenträger in Laufwerk C: ist OS
    Volumeseriennummer: DA39-2EBA
    Verzeichnis von C:\Privat\BTSync\Daten\unRAID\Dump
    29.05.2013 20:20 <DIR> .
    29.05.2013 20:20 <DIR> ..
    29.05.2013 18:36 12.816 Tower disk01.txt
    29.05.2013 18:36 12.719 Tower disk02.txt
    29.05.2013 18:36 9.709 Tower disk03.txt
    29.05.2013 18:36 13.375 Tower disk04.txt
    29.05.2013 18:36 8.838 Tower disk05.txt
    29.05.2013 18:36 2.526 Tower disk06.txt
    29.05.2013 18:36 2.440 Tower disk07.txt
    29.05.2013 18:36 2.072 Tower disk08.txt
    29.05.2013 18:36 2.360 Tower disk09.txt
    29.05.2013 18:36 1.174 Tower disk10.txt
    29.05.2013 18:36 62 Tower disk11.txt
    29.05.2013 18:36 62 Tower disk12.txt
    29.05.2013 18:36 8.888 Tower disk13.txt
    29.05.2013 18:36 7.939 Tower disk14.txt
    root@Tower:/mnt/disk1/Privat/BTSync/Daten/unRAID/Dump# ls -lisa
    total 281
    406474 1 drwxrwxrwx 2 nobody users 1168 2013-05-30 13:45 ./
    303584 0 drwxrwxrwx 8 nobody users 376 2013-05-09 10:58 ../
    526075 16 -rw-rw-rw- 1 nobody users 12816 2013-05-29 18:36 Tower disk01.txt
    487705 16 -rw-rw-rw- 1 nobody users 12719 2013-05-29 18:36 Tower disk02.txt
    526076 12 -rw-rw-rw- 1 nobody users 9709 2013-05-29 18:36 Tower disk03.txt
    526077 16 -rw-rw-rw- 1 nobody users 13375 2013-05-21 17:38 Tower disk04.txt
    526054 12 -rw-rw-rw- 1 nobody users 8838 2013-05-26 15:44 Tower disk05.txt
    487732 4 -rw-rw-rw- 1 nobody users 2526 2013-05-20 20:27 Tower disk06.txt
    526060 4 -rw-rw-rw- 1 nobody users 2440 2013-05-20 20:27 Tower disk07.txt
    526074 4 -rw-rw-rw- 1 nobody users 2072 2013-05-20 20:27 Tower disk08.txt
    526045 4 -rw-rw-rw- 1 nobody users 2360 2013-05-20 20:27 Tower disk09.txt
    526073 4 -rw-rw-rw- 1 nobody users 1174 2013-05-21 17:38 Tower disk10.txt
    526210 4 -rw-rw-rw- 1 nobody users 62 2013-05-20 20:27 Tower disk11.txt
    526213 4 -rw-rw-rw- 1 nobody users 62 2013-05-20 20:27 Tower disk12.txt
    515392 12 -rwxr-xr-- 1 nobody users 8888 2013-05-29 18:36 Tower disk13.txt*
    515029 8 -rwxr-xr-- 1 nobody users 7939 2013-05-29 18:36 Tower disk14.txt*

  13. Unfortunately this is not a conflict. You have two files with different timestamps, so Sync needs to choose oldest one and overwrite with newest one.

    Aha, if one node copies an older file over an existing file and the timestamp of that file is older than the timestamp of the last completed syncronization: This is no conflict?

    OMG. Seems that I need to remove BTSync from all my machines. We have lots of use cases where old files are put into the game again. Now I do understand lots of the problems I've seen in the past ...

    In addition: BTSync itself behaves different in some situations. If you copy a file over an existing file and this file has the same content you don't copy this file, you don't even attach the new timestamp the the existing file on other nodes. So you produce files with different timestamps. I can't imaging what problems will arise from that ...

  14. Assume you have file 1.txt with timestamp of May 28. It was synchronized across computers. Then you move the file 1.txt inside the Sync folder and this file has timestamp May 26. If we compare only timestamps, May 26 will be overwritten by May 28 file from other computer. And this is not what you would expect.

    Sorry for buttin in:

    This is a true conflict. In that case both files should survive. The new and older file should be synced with a comment (e.g. "1 (conflicting version from node xyz).txt".

  15. I don't believe at present you can do "beginning with" matches in .SyncIgnore - it would be great if you could do full REGEX matches in .SyncIgnore, but at present, only the "?" and "*" wildcards are available (in REGEX syntax, matching files that start with a "~" would simply be "^~" (no quotes))

    Hm, please have a look at the default entries in .SyncIgnore. What does "._*" (without quotes) mean then? Especially the * at the end would be quit confusing then. "._" would be enough then.