Search the Community

I've set up a sync and notice that on the receiving machine, the 'size' column display the size of the files received at a particular point in time rather than the total size of the files in the remote folder. I feel it would be of value to see the total size of the remote folder so that I know what to expect! I know the progress indicator gives some idea by way of the % complete indicator but a numerical value would be nice.

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