Error when using a batch file with v 10.6 that works OK with v 10.5

[Andy Wright]

I have a backup set up that synchronises Z:\ with W:\ - the ffs_batch file I use is attached.

This has been working fine for a long time.

Yesterday I installed v 10.6 of FreeFileSync and when I tried to run the synchronisation I got the following error:

"One base folder of a folder pair is contained in the other one.
The folder should be excluded from synchronization via filter.
W:\
W:\
You can switch to FreeFileSync's main window to resolve this issue"

I cancelled it, uninstalled v 10.6 and re-installed v 10.5 which fixed the problem.

Is there a known issue with v 10.6 or do I need to change something?

Thanks.

[Zenju]

It could be that your Z: and W: drives have an identical device serial number. To verify you could log a Process Monitor trace for the time when the error comes up:
https://freefilesync.org/faq.php#trace

[MartinPC]

No, I'm pretty sure that one of the changes in 10.6 has had an unanticipated, unwanted side effect and that folders with identical paths that are on different drives are mistakenly being identified as being on the same drive.

I have essentially the same problem as Andy Wright.

I have one local primary MBR Windows 7 system drive C: (volume label "T510 System") and one local secondary MBR drive D: (volume label "T510 Clone"). I periodically clone the system drive to the secondary drive using Macrium Reflect. Between clonings, I keep select folders on the clone drive up to date using FreeFileSync batch jobs and (for some of the batch jobs) RealTimeSync tasks. The folder paths on each side of each folder pair are identical; only the drive letter/volume label differs.

The two drives have different manufacturer serial numbers. In my folder pairs, I use drive letter C: for the left side and volume label [T519 Clone] for the right side. Macrium Reflect doesn't automatically restore the target drive's original volume label after cloning, so after each cloning I manually reset the clone drive's volume label from "T510 System' to "T510 Clone". (If I don't, my FFS batch jobs and RTS tasks won't run because there is no drive on the computer labeled "T510 Clone" until I do.)

My batch jobs have been working fine through many versions of FFS until 10.6. Since installing FFS 10.6, I'm getting essentially the same warning message as Andy Wright. Again, my C: drive's volume label is "T510 System" and my D: drive's volume label is "T510 Clone", but all of the folders on the right that begin with [T510 Clone]\ are being misidentified in the warning message as beginning with C:\.

There is a further twist in that two of my batch jobs that are designed exactly the same way as the others -- same destination drive and target drive, same use of drive letter on the left and volume label on the right -- are *not* throwing the warning.

At any rate, the key takeaway is that all of my jobs were working fine in FFS 10.5 and that I didn't change any of them or clone my drives or change any of their volume labels before updating from FFS 10.5 to 10.6.

Like Andy, I will be downgrading to FFS 10.5 until this bug is diagnosed and fixed. (Could it be a problem with how 10.6 "detects and skips traversing folder path aliases"? I'm just guessing...)

Thanks, zenju!

[Proger]

It is possible to disable this feature for some disks/folders?
I synchronize two virtual disks, mounted on a different disk letter: the main disk, and backup, which are the full copy of the main disk, i.e. the serial number at them coincides..

[akamaka]

In my case viewtopic.php?t=5814&p=19224#p19224 I am pretty sure they have the identical device serial number as hey are identical TrueCrypt containers stored in different places.
However this does not happen with 10.1 ( i skipped the 10.5)

[Andy Wright]

Hi Zenu,

Thanks for your reply. Having checked the drives concerned (Z: and W:) using the following in a command window:

vol w:
vol z:

They do indeed have the same volume serial numbers.

I think the issue is a bit like the described by akama.

I set up z: using Veracrypt.

I then created w: as a backup by copying the container of z: hence I think the reason for the same serial numbers.

At that point FFS v 10.5 (and earlier) had no problem in synchronising z: to w: to maintain w: as a valid backup.

The problem in synchronising seems to be a result of new features introduced in FFS 10.6

I'm looking into software that will let me change the volume serial numbers to see if this solves the problem.

[Andy Wright]

I used volumeid from here:

https://docs.microsoft.com/en-us/sysinternals/downloads/volumeid

as follows to change the serial number of W:

1) Mounted drive Z: and W: using veracrypt.

2) Displayed the volume ids in an administrator command prompt window:

vol z:
Volume in drive Z has no label.
Volume Serial Number is 1809-16BB

vol w:
Volume in drive W has no label.
Volume Serial Number is 1809-16BB

3) Downloaded the volumeid software and unzipped it to a folder named C:\Downloads\VolumeId\VolumeId>.

4) Ran the following in an administrator command prompt window:

cd C:\Downloads\VolumeId\VolumeId

volumeid64 W: 1809-16CC

VolumeId v2.1 - Set disk volume id
Copyright (C) 1997-2016 Mark Russinovich
Sysinternals - www.sysinternals.com

Volume ID for drive W: updated to 1809-16cc

5) Used veracrypt to dismount W: then re-mount it.

6) Checked the volume id:

vol w:
Volume in drive W has no label.
Volume Serial Number is 1809-16CC

After that I updated FFS to v 10.6 and was able to synchronise Z: to W: without a problem.

[Zenju]

The latest few FFS releases have made great progress towards full cross-platform support of (device-dependent) case sensitivity and unicode normalization forms, and I'm planning to finish this area in 10.7.
e.g. it will be possible to correctly handle case-insensitive network shares (e.g. mounted NTFS drive) on Linux, and the reverse of e.g. a case-sensitive Linux-hosted SFTP device on Windows, as well as macOS's decomposed-Unicode-enforcing HFS+ filesystems in all combinations.
This replaces the rather simplistic old platform-specific file path handling, but unfortunately we have a regression here with the folder existence checks.

Since 10.6 is relatively new and there are not too many downloads yet, I've patched this part of the code to use the old platform-specific file path handling and updated the official FFS 10.6 download link on the homepage.

PS: Making sure that different devices have different serial numbers, as Andy Wright did, will also do as a workaround.

[MartinPC]

Again, my strategy for rapidly recovering from a dead or corrupted system drive involves using Macrium Reflect to periodically clone my Windows 7 system drive and using FreeFileSync and RealTimeSync to keep user data and select configuration data on the clone drive up to date between clonings. (Done right, this allows you to get back up and running within five minutes of a catastrophic system-drive failure with practically no data loss, minimal configuration-change losses, and only a moderate amount of software updating to be redone.)

Following up on Andy Wright's most recent posts, I checked my two drives' volume serial numbers and found that they are in fact identical -- as one should expect of an original drive and its clone.

Some software licensing schemes (including Windows') rely on volume serial number to ensure that the software in question isn't being used on a system it wasn't licensed for. The clone drive's volume serial number must remain the same as the original system drive's to avoid license validation problems if and when the clone is used as the new system drive (whether temporarily, for testing, or permanently, because the original drive is kaput).

If the clone drive's volume license number must be manually changed in order for FreeFileSync to work, and then manually changed back to the original volume license number before it can be used as a system drive, that introduces an unwelcome additional complication. I've set up recovery systems similar to mine for friends and relatives who are even less technically literate/competent than I am. I've taught all of them how to make sure their RealTimeSync tasks are actually running, and the slightly more tech-literate among them how to clone, how to manually run their batch jobs in FreeFileSync's GUI to make sure nothing is amiss, and how to swap in a clone drive. But keeping records of original volume serial numbers, manually changing volume serial numbers after each cloning, and manually changing them back before booting to a clone is probably beyond most of them.

Note that if the issue is in fact identical volume serial numbers, I'm still puzzled as to why a couple of my batch jobs that were "structurally identical" to the others -- containing folder pairs with identical paths on both sides, on drives with different drive letters and volume labels but identical volume serial numbers -- ran without a hitch on the original 10.6 release while the other jobs threw warnings (and in one case an error). The only difference I could see between the batch jobs that ran okay and the batch jobs that didn't was that the ones that continued running okay were for "shared" data under C:\Users\Public, which on my system contained no user-created files. But I added a new dummy text file to one of the folders, and the job continued to run without a hitch. Go figure...

I don't know what the long-term solution should be, but for now I hope that reverting to platform-specific path handling in the revised 10.6 release will fix the problem.

Many thanks, zenju, for your continued work on this. If I run into trouble with the revised 10.6 release, I'll follow up with another post.

(And thanks, too, to Andy Wright, for his very clear and helpful follow-ups!)

[MartinPC]

The revised release of 10.6 appears to have fixed the problem. (I didn't get any warnings or errors when running any of my system-drive/clone-drive batch jobs.) Thank you!

[Zenju]

Here's the proper fix (without relying on volume serial numbers) that will be used in the next release:
http://www.mediafire.com/file/w8m18e8u9r7d648/FreeFileSync_10.7_%5BBeta%5D_Windows_Setup.exe