okibcn

This is a good Idea. So far .SyncIgnore configuration file CAN be different in each peer because it is not synced by the application (is this a bug?). Should this be a problem, I mean to have different .SyncIgnore files, the app should sync it as soon it is modified in any of the peers. Otherwise my proposal is to have two files: .SyncIgnoreUp and .SyncIgnoreDown. SyncIgnoreUp will not publish local files in this file, while .SyncIgnoreDown is the exclusion list that the user doesn´t want to download in that peer. My other abd recommended proposal is to have just one file in each peer as it is now (equivalent to the .SyncIgnoreDown of my first proposal), Then the peers of a folder check the local and remote .SyncIgnore files to create the queue of files to sync between those two peers. This would create a rule when two peers have different .SyncIgnore files, giving this way a new functionality to the app. Regards

My vote on this too. folders dates are as important as files dates.

Thanks RomanZ, Let me ask this question, is it possible to include this functionality in the protocol as a new feature? I mean, it would be easy for the peers to check whether the file matches also the syncignore file of the other peer when trying to upload/download. In mi case the BT sync running in the video server would check the syncignore file of the picture server to check whether it can be considered already uploaded/discarded. Obviously in the download direction the BT sync will never request a file that matches one of the rules in it's local syncignore file but it should also check whether a missing file in the other peer is because it has been deleted or, maybe, because it matches the other peer's sincignore file. It could be a nice and easy addition to the official functionality of BTSync, or at least an option for each folder. Otherwise, if having different syncignore files is dangerous, for safety reasons, you should make syncignore file part of the synced list of files to ensure that all the peers have the same file for exclusions. Regards

My pleasure. Will this issue be fixed in the next beta release? Thanks for this little great tool!

I have found a bug that might be causing the partial indexing effect that you are seeing. I have a similar problem. I have posted a workaround for this bug found in release 1.3.94 here: http://forum.bittorrent.com/topic/29689-indexing-stops-when-a-non-accessible-folder-is-found/ Hope it helps.

I would like to setup selective backup servers of a huge multimedia folder tree. I have mixed videos and pictures in a folder tree. I would like to have a backup server only for video and other only for pictures. The proposed setup is composed of 3 R/W nodes: A. Main server: Including all the files B. Video server: Filtering out the picture extensions and docs in .SyncIgnore file C. Pictures server: Filtering out the video extensions and docs in .SyncIgnore file My questions: 1. Is it possible to have 3 nodes with different .SyncIgnore files? 2. Is there any side effect? Thanks

I have found a problem in the indexing code of BTSync. I had a huge problem when trying to Sync a huge folder. The size and number of files didn't matched. I have enabled the debug log, started a fresh installation of BTSync 1.3.94 on a Server 2003 machine. Indexing process stopped at about 15% of the size and files. The relevant part of the Sync.log file shows: [2014-05-01 09:47:41] SyncFilesController [file updated]: Processing file \\?\D:\Main\2009\A\Photo Reg Templates\PhotoReg Temp.doc 1350671957 157696[2014-05-01 09:47:41] SyncFilesController [file updated]: Processing file \\?\D:\Main\2009\A\Photo Reg Drafts 1344981169 0[2014-05-01 09:47:41] SyncFolderScanner: GetFileList failed for folder \\?\D:\Main\2009\A\Photo Reg Drafts - error -1[2014-05-01 09:47:41] SyncTrashFolder: Sync trash scan for folder "\\?\D:\Main\.SyncArchive" started, max file age = 30 days[2014-05-01 09:47:41] SyncTrashFolder: Sync trash scan for folder "\\?\D:\Main\.SyncArchive" finished Looking at the folder properties of \\?\D:\Main\2009\A\Photo Reg Drafts, I´ve found that somehow that folder had no owner in the security tab of that folder properties. Thus the folder was not accesible even for the Administrator. The Indexing process of BT sync stops as soon as it finds a non accesible folder due to this, reporting "error -1" in Sync.log (see dump above) and bypassing the rest of the folder tree. The troubleshooing was easy, I had to restore the ownership of that folder back to the Administrator. I then deleted the folder from BTSync and start again the whole indexing with a new secret. It is painful for all the nodes, but it solved the problem. I find more appropiate the indexing code to bypass the non-accessible folder and continue with the rest of the folder tree. This is why I consider this a bug in the indexing code. A warning tab reporting the issue to the user that that folder is unaccessible would be welcome. Thanks

I have a similar behaviour in my setup under release 1.3.93 and probably 1.3.94 (just updated it) I have a folder synced. It was originally in Computer A and now it is syncing to site B. Both are Windows Server 2003 machines. The folder size is about 500 GB in size, about 100K files and 7K subfolders. The structure is something like this: \main \main\A\.. \main\B\.. \main\C\.. \main\D\.. \main\E\.. I synced a subfolder (lets say \main\A) first between both machines with a random secret and It was fine. Now I am trying to sync the parent folder, the entire site. I did: 1 I stopped BTSync in both sites, removed the \main\A folder in both My Sync tabs at both sites. 2 I deleted the .sync* files and folders in both sites. 3 I created a new secret for the \main folder in site A, where the information is stored. 4 I used the read only secret in site B to sync the \main folder. I expected that the rest of the \man\* to sync as successfuly as the \main\A did. I also expected the files and folders under \main\A was not transfered again since the mtime and size were the same as they where the result of a previous synced folder. To my surprise only subfolders main\A and main\B, and modified files in the whole \man\* tree, are synced. Also to my surprise, in My Sync tab the \main folder appears as having only 91.8 GB and about 73K files when it actually have 504GB and more than 100K files. I excluded the video files in the .syncignore file in site B but videos are just 150GB and I am missing 410 GB in site B. I have just updated to 1.3.94 and the folder size reports the same incorrect size. Thnaks for your work, I know that it is still in beta stage and I am happy to help on making this a better tool.

I´d like to have this feature. This would help on downloading subfolders of the sync folder in a selected order when they are ready to be synced. Regards

My wishlist: 1. PLEASE!!! Compression: BTSync uses a lot more bandwidth than DropBox, Gdrive and similar. Same with duplicated files, the downloading peer should dl only one instance, but implementing this might be difficult depending on the internal bt protocol. 2. Backup secret: To ensure that the deleted files in the source are not deleted in the destination. A kind of read only destination once the files are uploaded. This is like a Forbid delete files flag for that folder and not seeding that folder. 3. Install a as a service in Windows with a management GUI. Web management would be awesome!!! Thanks for asking!!!

The bug reporting instructions and how to collect debug data is in the pinned threads of this forum at http://forum.bittorrent.com/topic/12658-if-you-have-syncapp-issue/

I've found a similar problem with a group of JPG with mdate in year 2098. The procedure I did was: 1 - Close BT Sync in all sites. 2 - Change the date of the files with invalid mdate with BulkFileChanger in all sites (it is a nice Windows software that doesn't need to be installed, AKA greenware). 3 - Run BT Sync again in all sites. In case BT Sync restores the old invalid date, then the solution wuld be removing the sync folder with invalid files in all sites, do step 2 and after that create a new secret and sync the folder tree with the new secret. This will take more time, but is a definitive solution.

Thanks RomanZ. I have checked the details of those files. They all had the modified dates in the future. Reading the forums I learned that BT Sync can not sync files modified in the future. I just copied the creation date into the modified date of those files and the issue is gone forever. No more indexing cycles and eternal "Updated file" messages related to those files. I can understand that limitation of BT Sync, the modified datestamp is basic to keep new files, but those files should have been marked somewhere just to avoid BT Sync to re-index those files every 26 seconds. It is a waste of BW, cycle time, log file space, CPU resurces, etc... Are you planning on integrating a workaround to, at least, generate a warning to the end user about those files with corrupted date? Thanks

What is the correct bug report email address, is it sync@bittorrent.com or syncapp@bittorrent.com? Thanks

I have 2 Server 2003 machines with BT Sync 1.3.87 for Windows. The administrator is the owner of the BT Sync task in both machines. Site A has many unchanged files (pictures, movies, zip files, etc...) and some files actively changed. It is a huge folder tree of 350GB that is now half uploaded to Site B using BT Sync. Site B is a backup machine and no other task is accessing the synced folders except BT Sync. The extrange behavior happens in Site B. Every 26 seconds the backup folder is indexing the very same 160 files (aprox.) and the message "Updated file XXXXXXXX" is shown in the history tab for each of those 160. Those files are, all of them, already sinced and they haven't ever been modified. All of them are JPG pictures of a collection of thousands. The sync of unsynced files seems to be running fine since there are active transfer of files (none of those 160) in the Transfers tab. Closing and running again BTSync doesn't fix the issue, even more, it seems that doing this causes the issue. Only removing the folder from My Sync tab and adding it again to reindex the whole collection again solves the issue. The described issue appears in the next reboot of the computer or the BT Sync application. Any idea on how to avoid it? Thanks

It sounds like a BACKUP SECRET added to the current RW SECRET and RO SECRET syncronization modes. But the idea is to do the mirroring in real time (almost that). This new mode would solve the backup problem with the pictures and videos in the mobile phone. Many people would like to have automatic uploads and being able to delete files from the phone while keeping them in the backup folder.

Thanks noiime, I was asking that because I really don't know whether BTsync is doing some kind of compression for faster transmission. This way the effective transmission rate would be faster than the used BW. Regards

So, while you release a new version, what is the effective transmission rate, the sum of each file or the one displayed in the bottom? Thanks

I am using BTsync 1.3.80 in 2 windows sites. I am now dowloading from site A to site B and it will take a few days to sync completely. The issue is that in site B the total down speed in the bottom of the app window is from 1.5 to 2 times the sum of total speed. Site B is dowloading now at a sustained rate of 210 kB/s at the bottom of the screen while the sum of the three dowloads at this time is 101 kB/s. What is the effective transmission rate? The same can be seen in site A but in the up direction. It has been behaving like this for days now. What is the explanation of that behaviour? Is BTSync using twice the amount of the effective bandwidth? Thanks Edit: Found another thread reporting this issue in version 1.3.80: http://forum.bittorrent.com/topic/29235-wrong-transfer-speed-status/ so no need for this thread, sorry about that..