okibcn

Members
  • Content Count

    19
  • Joined

  • Last visited

About okibcn

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  1. 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 a
  2. My vote on this too. folders dates are as important as files dates.
  3. 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 ch
  4. My pleasure. Will this issue be fixed in the next beta release? Thanks for this little great tool!
  5. 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.
  6. 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? Thank
  7. 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:\Ma
  8. 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 BTSy
  9. 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
  10. 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 awe
  11. 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/
  12. 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
  13. 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
  14. What is the correct bug report email address, is it sync@bittorrent.com or syncapp@bittorrent.com? Thanks
  15. 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 histor