cactustak

I'm running a Windows 8.1 system, using the NTFS file system ; Sync Pro version 2.3.3 (296) I need to provide some background first, then I'll provide details of the bug. Background: I have 3 hard drives, all local. Drives C:, D: and L: I have a folder L:\real_data where my actual data is located I have 2 subfolders - L:\real_data\data_01 and L:\real_data\data_02 I have populated each of data_01 and data_02 with some test data (a file, and a subfolder with a file) I have a folder d:\000_data_junctions I have created a junction d:\000_data_junctions\data_01 to L:\real_data\data_01 The command I use for that is: mklink /j d:\000_data_junctions\data_01 l:\real_data\data_01 doing a dir /s of d:\000_data_junctions\data_01 shows the expected data - the contents of L:\real_data\data_01 I have created a junction d:\000_data_junctions\test_data_02 to L:\real_data\data_02 The command I use for that is: mklink /j d:\000_data_junctions\test_data_02 l:\real_data\data_02 doing a dir /s of d:\000_data_junctions\test_data_02 shows the expected data - the contents of L:\real_data\data_02 Note the name of this junction is different than the target folder (test_data_02 vs data_02) - a perfectly valid thing to do from a file system persepctive I have created the folder c:\000_shares\000_btsync\zz_test_03 So far, all of the above is regular Windows file system stuff, and is all working as expected. I add c:\000_shares\000_btsync\zz_test_03 to btsync ; added successfully, and currently empty. So far so good. Now, the steps to reproduce the bug. Scenario #1 In c:\000_shares\000_btsync\zz_test_03, I create a junction called data_01 to d:\000_data_junctions\data_01 The command I use for that is: mklink /j c:\000_shares\000_btsync\zz_test_03\data_01 d:\000_data_junctions\data_01 doing a "dir /s" of c:\000_shares\000_btsync\zz_test_03\data_01 shows the expected data - the contents of L:\real_data\data_01 btsync indexes the shared folder c:\000_shares\000_btsync\zz_test_03 properly - showing the proper size of the target Scenario #2 Next, in c:\000_shares\000_btsync\zz_test_03, I create a junction called test_data_02 to d:\000_data_junctions\test_data_02 The command I use for that is: mklink /j c:\000_shares\000_btsync\zz_test_03\test_data_02 d:\000_data_junctions\test_data_02 doing a "dir /s" of c:\000_shares\000_btsync\zz_test_03\test_data_02 shows the expected data - the contents of L:\real_data\data_02 btsync DOES NOT index the contents of c:\000_shares\000_btsync\zz_test_03\test_data_02 properly Scenario #3 Next, I create a new junction for L:\real_data\data_02 called d:\000_data_junctions\data_02 - note this time the names match The command I use for that is: mklink /j d:\000_data_junctions\data_02 l:\real_data\data_02 Next, in c:\000_shares\000_btsync\zz_test_03, I create a junction called data_02 to d:\000_data_junctions\data_02 The command I use for that is: mklink /j c:\000_shares\000_btsync\zz_test_03\data_02 d:\000_data_junctions\data_02 doing a "dir /s" of c:\000_shares\000_btsync\zz_test_03\data_02 shows the expected data - the contents of L:\real_data\data_02 btsync correctly indexes the contents of c:\000_shares\000_btsync\zz_test_03\data_02 properly Scenario #4 Next, in c:\000_shares\000_btsync\zz_test_03, I create a junction called foofoofoo to d:\000_data_junctions\data_01 The command I use for that is: mklink /j c:\000_shares\000_btsync\zz_test_03\foofoofoo d:\000_data_junctions\data_01 doing a "dir /s" of c:\000_shares\000_btsync\zz_test_03\foofoofoo shows the expected data - the contents of L:\real_data\data_01 btsync DOES NOT index the contents of c:\000_shares\000_btsync\zz_test_03\foofoofoo properly Conclusion: - btsync fails to index data using junctions if, at some point, any of the names differ from what is actually on the file system (Scenarios 2 and 4) - this started happening fairly recently. Honestly, I can't recall a specific date, but I'm positive it was working in December 2015, so this bug must have been introduced sometime in 2016. - the short answer as to why I'm creating a network of symbolic links, is that it allows me to abstract where the data actually resides from what's being shared in BTsync - I can move the data around as I see fit (wrt folder and drvie paths), but do not have to touch the BTsync configuration itself. This has been working for years - as long as I've been using BTsync - so I'm nut sure what broke ... hoping it's a quick fix. Please let me know if you need more information. Thanks in advance! -kevin

Hi RomanZ. I'm running Windows 8.1 64-bit with IE11. Thanks,

Hello there GreatMarko and all the other Bittorrent Sync folks! First time posting, so let me start by offering a big THANKS! for this tool. Making great use of it keeping things like music files in sync between my devices! I've recently upgraded to the Windows 64-bit v1.4.83 version, and I've noticed a couple of UI bugs/oddities I thought I would mention. 1) If I open the UI, and keep the window open but (for the most part) minimized, except for when I'm working in it/looking at it, the following happens after a while ... I don't have a precise timeframe, but I'd say after 6+ hours at least: - when I bring up the UI, the shared folders list only displays lines up to where the mouse pointer is. - if I move the pointer down, more shared folders are displayed - if I move the pointer up, fewer folders are displayed - closing the window and re-opening the window solves the problem, but I don't think this should be a problem in the first place, should it? 2) no vertical scroll bars - I have a large number of shared folders - 16 at the moment - and I basically have to have the window maximized to see them all ... navigating to folders not shown is a bit of a pain, in that one has to select a folder, then use the arrows to scroll up/down to bring the other folders into view, and the last folder is only about 3/4 in view. Hopefully you can add a vertical scroll bar to make the UI a little cleaner to use? Thanks in advance!