You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As it happens, I use alternate data streams (ADS) on NTFS and ReFS to store file checksums (using RapidCRC) to guard again bitrot.
When investigating a pretty large discrepancy in free disk space between physically and logically identical disks, where WinMerge reported that the contents were definitely fully identical, I figured out that, apparently, WinMerge will currently ignore any ADS of files, regardless of what type of comparison is used.
When searching about this, I found a possibly relevant changelog: "WinMerge 2.16.29 - 2023-03-21", which refers to the fixing of a bug when an ADS is passed on the cli. So, the concept is clearly not unknown to the developers :)
Is there an option I've missed to turn comparison of the entire file, including any ADS, on?
If not, can support for this be implemented? ADS are pretty well documented, and it seems to me this would mostly require a change in how files to be compared are enumerated, not in the code that does the actual comparison.
It's been decades since I've wrote any code, but I imagine it entails:
checking whether a file resides on a file system that supports alternate data streams (eg. NTFS/ReFS), something that probably only has to be done once when enumerating the drives, and then cached with the rest of the drive information, and,
when enumerating files, adding a check for alternate data streams, enumerating those (or perhaps just always enumerate ADS, depending on how expensive this is resource-wise), and then enqueueing the alternate streams as seperate files internally.
Given the changelog entry, it seems the comparison code is already perfectly able to handle them right now.
Currently, WinMerge will definitively state files are identical, even if one of them could have gigabytes stored in an alternate stream that the other "identical" file doesn't.
Additionally, it will also determine files tagged as "from the Internet" and those that aren't to be identical. This is because windows/explorer stores this information in the "Zone.Identifier" ADS (it will also store some thumbnail information in an ADS, too).
Microsoft Word incidentally also uses the "Zone.Identifier" ADS to make security context judgements about a file being opened, so the difference isn't trivial.
Just in general, when WinMerge is used to make sure a backup is identical to the source (as in my use-case), and ADS are used in any way, WinMerge currently will give a false sense that everything is indeed fully identical, when I fact it isn't.
Thank you for your time. I'm willing to alpha/beta test if that helps.
The text was updated successfully, but these errors were encountered:
Dear developers,
First: thanks for a great tool!
As it happens, I use alternate data streams (ADS) on NTFS and ReFS to store file checksums (using RapidCRC) to guard again bitrot.
When investigating a pretty large discrepancy in free disk space between physically and logically identical disks, where WinMerge reported that the contents were definitely fully identical, I figured out that, apparently, WinMerge will currently ignore any ADS of files, regardless of what type of comparison is used.
When searching about this, I found a possibly relevant changelog: "WinMerge 2.16.29 - 2023-03-21", which refers to the fixing of a bug when an ADS is passed on the cli. So, the concept is clearly not unknown to the developers :)
Is there an option I've missed to turn comparison of the entire file, including any ADS, on?
If not, can support for this be implemented? ADS are pretty well documented, and it seems to me this would mostly require a change in how files to be compared are enumerated, not in the code that does the actual comparison.
It's been decades since I've wrote any code, but I imagine it entails:
checking whether a file resides on a file system that supports alternate data streams (eg. NTFS/ReFS), something that probably only has to be done once when enumerating the drives, and then cached with the rest of the drive information, and,
when enumerating files, adding a check for alternate data streams, enumerating those (or perhaps just always enumerate ADS, depending on how expensive this is resource-wise), and then enqueueing the alternate streams as seperate files internally.
Given the changelog entry, it seems the comparison code is already perfectly able to handle them right now.
Currently, WinMerge will definitively state files are identical, even if one of them could have gigabytes stored in an alternate stream that the other "identical" file doesn't.
Additionally, it will also determine files tagged as "from the Internet" and those that aren't to be identical. This is because windows/explorer stores this information in the "Zone.Identifier" ADS (it will also store some thumbnail information in an ADS, too).
Microsoft Word incidentally also uses the "Zone.Identifier" ADS to make security context judgements about a file being opened, so the difference isn't trivial.
Just in general, when WinMerge is used to make sure a backup is identical to the source (as in my use-case), and ADS are used in any way, WinMerge currently will give a false sense that everything is indeed fully identical, when I fact it isn't.
Thank you for your time. I'm willing to alpha/beta test if that helps.
The text was updated successfully, but these errors were encountered: