Bug : sync not indexing data when using NTFS junctions

[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

 

[GreatMarko]

Please see: Soft Links, Hard Links and Symbolic Links in the Sync Help Center:

On Windows "Sync doesn't support soft links (junctions), hard links or symbolic links. The use of such links may lead to the appearance of .Conflict files for each entry (file or folder)."

...so not a "bug" as such, more a "limitation" due to "issues in WinAPI".... "it is highly not advised to add to Sync any paths containing Junctions. Use only real paths."