hawibtsync

Members
  • Posts

    60
  • Joined

  • Last visited

  • Days Won

    1

Everything 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.pdfI 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.confI 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.JPGI 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. I don't understand parts of the readonly secret functionality. I did understand that files/folders that become deleted/changed on the receiver-side do not lead to changes on the sender-side. But what happens if the sender adds more data to this folder? Will the receiver of a readonly secret get them? Thanks a lot in advance. Jury
  6. I can confirm that with an AVM WLAN Repeater N/G. I'm using this WLAN Repeater since several years now. I never had any problems with this device. Whenever I start the BTSync App on one of my Android Devices after 10-15 minutes the Repeater crashes. I need to unplug the repeater from power, wait a minute and plug it in again.
  7. 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...
  8. On my Windows 8 machine BTSync is re-indexing my shared folders (lots of shared folders, lots of storage) permanently. I have to kill BTSync if I need to do heavy file operations. Why does BTSync do that? Don't you trust the Windows file system hooks? On Linux it depends on special packages if and how these hooks work, but on Windows 8 ...? Simply try to understand this.
  9. 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?
  10. Windows 8 PCs, all on 1.1.27. "Search LAN" is the only enabled option on all my folder shares. I do see lot of traffic going to and coming from 239.192.0.0. BTSync is the process doing that traffic. What is this? In fact it's the connection that shows the most network traffic out of my LAN. TIA
  11. 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?
  12. * 1.15 on i386 and Windows 8 * 1.14 on Android
  13. 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.
  14. 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
  15. 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
  16. 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.
  17. 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*
  18. 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 ...
  19. 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".
  20. 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.
  21. I didn't receive an answer so I tried "~*" (without the surrounding quotes) in all .SyncIgnore files. Seems to work.
  22. A minor wish: Sortable columns in WebUI and Windows Application.
  23. Windows 8 - Version 134 I do have unset the option "Delete files to sync trash" on all Folder Shares. But whenever I start the Application the folder ".SyncTrash" is recreated again - even if it was removed before. Thanks for listening.
  24. I would like to ignore all those temporary files that start with ~. What do I need to enter in the ignore file on Windows and Linux? TIA