Request: Fix parsing of volume GUIDs in pathnames

[trgoodman]

In the pathnames for FreeFileSync, I used to use volume GUIDs to avoid ambiguity about the source and destination. Volume GUIDs are almost-permanently assigned to storage devices. For example:
The left pathname: \\?\Volume{*GUID A*}\DocsToRead
The right pathname: \\?\Volume{*GUID B*}\ReadThis

Starting with some version of FreeFileSync around July or August, it could no longer parse volume GUIDs. Now I have to resort to the much more flakey approach of using drive letters, which change all the time:
The left pathname: P:\DocsToRead
The right pathname: G:\ReadThis

Since the devices holding directories "DocsToRead" and "ReadThis" get assigned different drive letters depending on what is going on with the system, I have to keep checking and changing the drive letters in the pathnames in FreeFileSync.

Could the correct parsing of volume GUIDs be brought back?

[Zenju]

I'm surprised this was ever working, at least support for path by volume id was not deliberate functionality. The proposed solution for this scenario is to specify the path by volume name: see help file chapter "Variable drive letters".

[trgoodman]

I'm surprised this was ever working, at least support for path by volume id was not deliberate functionality. The proposed solution for this scenario is to specify the path by volume name: see help file chapter "Variable drive letters".

It would be worth looking at the old code to see if volume GUIDs could be used again. A GUID is a more rigorous way of identifying a device than using volume labels (which do not need to be unique). What if someone has a system partition labeled "OS", and a clone that also has "OS", then wants to sync between the two? That is just one example of many possible.

[Zenju]

It would be worth looking at the old code to see if volume GUIDs could be used again. A GUID is a more rigorous way of identifying a device than using volume labels (which do not need to be unique). What if someone has a system partition labeled "OS", and a clone that also has "OS", then wants to sync between the two? That is just one example of many possible.

The volume GUID syntax is not supported by most higher-level Windows APIs. It should work for lower-level kernel APIs though, which comprise most of what is required for synchronization. Things like showing file icons, or recycle bin usage OTOH won't work.
If desperately needed, and using unique volume names is too much of a burden, it can still be used by specifying the prefix twice like:

\\?\\\?\Volume{542f5023-6ee2-4f8a-9543-e55194f83cb8}\subfolder

[trgoodman]

The volume GUID syntax is not supported by most higher-level Windows APIs. It should work for lower-level kernel APIs though, which comprise most of what is required for synchronization. Things like showing file icons, or recycle bin usage OTOH won't work.
If desperately needed, and using unique volume names is too much of a burden, it can still be used by specifying the prefix twice like:

\\?\\\?\Volume{542f5023-6ee2-4f8a-9543-e55194f83cb8}\subfolder

I tried the double-prefix method and it works fine, thanks. But why only "if desperately needed"? Is there some danger that this will break something? I described the advantages above.

[gandlz]

I know this is a very old post but the problem was just present to me. I found the following workaround: (maybe it’s already mentioned somewhere else)

In Windows Disk Management, where you add or change the drive letter, you can also add a NTFS-Path (additional to the drive letter). So create an empty folder like C:\mount\Backup-HDD and choose that folder as NTFS-Path to mount. Independent from the drive letter or drive name, it is now always reachable through C:\mount\Backup-HDD. So use this Path in FreeFileSync.