Compare - with Alternate Data Stream

[Mati]

Recently I compared two folders with identical files on NTFS. This, Except that in one of the two folders METADATA was added to the files. [Specifically, tags were added to audio files of the AMR format, using the "Directory Opus" program].

Turns out that BC4 would mark the two folders as Identical because it compares only the default stream.

I am a registered user of BC4 and like the program. However, not being able to detect a change in the ADS, will render BC4 for me as useless, and potentially catastrophic as I rely on it for backup.

That is not an esoteric problem. There should be a mechanism to identify that the ADS has been changed, even if hte change itself must not be identified, or read.

I WISH THAT THE SCOOTER PEOPLE WOULD SOLVE THIS ISSUE -

[Aaron]

Sorry that we do not currently support comparing the alternate data streams. Our default compare is timestamp and size. We also support Content scans, like a binary scan, but this would not catch an ADS change. We appreciate the feedback, and I'll add your notes to our Customer Wishlist entry on the subject.

[Mati]

Suggestion

I dont know enough about the ADS. but I will make an educated guess and a suggestion:

I suppose that there must be some "size" (in bytes) to the alternate Data stream.
That "size" could be possibly read from the NTFS table and used for comparison without accessing the details of the content of that ADS.

This would be in line with the methodology of using "size" for comparison by BC.

[Aaron]

The alternate data stream does not represent itself as metadata like size or timestamp. Finding this information does require opening the file, and we would need to both interpret and present this information. It isn't a small change, but we've been gathering feedback on the subject.

[Mati]

Another suggestion

Thanks for your reply, Aaron.

I feel that I dont know enough about the NTFS file structure but I will venture to assume:
It seems to me that the NTFS tables must know where the ADS is located and its size.
Just as it knows where the default data stream (DDS) is located. Otherwise it could have not been able to allocate space correctly.
I am still guessing but in both cases I doubt that the NTFS opens the files in order to know this information bvecause this information must be readily available for copy and move operations.

If I am right, Would it not be possible for BC to get the information from the NTFS tables and save the time of opening each individual file. The fact that only the size of the data stream appears in a directory, could be only the choice of the designer in order to keep compatibility with FAT and somewhere else in the NTFS the size of the ADS hides.

It is only a hunch but i am curious what are BC's thoughts about it ?

Incidentally, I approached Directory Opus with a suggestion to allow for an option that when the ADS is changed then the "Date modified" will be updated. That would also solve my backup problem.
They replied that they will look into that but were not committed to doing it any time soon.

I am still hanging.

[Aaron]

Thanks. I'll check with a developer for details, but I'm pretty certain it does require opening the file but maybe not scanning the entire file. This is still a much heavier task than checking the provided metadata. And once we have it, we still need to add to the interface to control the importance of this scan, and display the results.

Does Directory Opus have a command to manually modify timestamps, similar to our "Touch" command? If it it were like BC4, you could select the files to act on, perform the action (which leaves them selected), then immediately perform the "Touch" action to then manually update their timestamps. Or, if this action can be done via the command line, you could create a custom Open With within BC4. This Open With would then be on BC4's context menu, could be activated on a selection, and then follow-up with a manual Touch.