BC3 Incorectly interprets Windows De-duplicated files as symbolic links

[BenMann]

My version is BC3.3.7

It seems that the problem is BC translates all files with the REPARSE_POINT attribute as symbolic links. If that's the case then it's incorrect as there are many other types of reparse points:

IO_REPARSE_TAG_CSV
IO_REPARSE_TAG_DEDUP
IO_REPARSE_TAG_DFS
IO_REPARSE_TAG_DFSR
IO_REPARSE_TAG_HSM
IO_REPARSE_TAG_HSM2
IO_REPARSE_TAG_MOUNT_POINT
IO_REPARSE_TAG_NFS
IO_REPARSE_TAG_RESERVED_ONE
IO_REPARSE_TAG_RESERVED_RANGE
IO_REPARSE_TAG_RESERVED_ZERO
IO_REPARSE_TAG_SIS
IO_REPARSE_TAG_SYMLINK
IO_REPARSE_TAG_WIM
(other values are also possible as Microsoft provide a mechanism for defining new tags)

Microsoft uses the REPARSE_POINT attribute with the IO_REPARSE_TAG_DEDUP tag in its de-duplication technology, which results in BC not being able to compare data on de-duplicated volumes :-(

Is it possible to clarify if that is the case and if so change the code to check the associated reparse point flag?

Thanks

[Aaron]

Thanks for the feedback. We do currently treat reparse_points similarly to symbolic links. Are they handled correctly for you if you go to the Folder Compare's Session menu -> Session Settings, Handling tab, and enable Follow symbolic links?

[BenMann]

Hi Aaron,

Yes, the "Follow symbolic links" option does get around the issue and does allow me to use BC on de-duplicated data. Thanks for pointing that option out.

In my oppinion though Reparse Points with any tag other than IO_REPARSE_TAG_SYMLINK should not be treated as symbolic links at all as other tags could cause other issues with BC in its current state. If you changed the code to work this way then the option would not be required to force BC to work with non-symlink reparse points.

We have 20 licenses and love this software so no criticism is intended here, just trying to suggest an improvement


Thanks,
Ben