Support Alternate Data Streams

Avatar
  • updated
  • Completed

Add Support for "Alternate Data Streams" when copying files that use it. This information is lost when copied with teracopy vs using windows explorer. I use Teracopy when copying TB of files. 

I make use of alternate data streams for MD5 Hash Checking. I am simply using MD5Stream to Store MD5 hash in NTFS Alternate Data Stream on the files. This way the MD5 is attached with the file.

Avatar
65
swarup manna

I use FileMeta a lot to add various metadata to different kind of custom filetypes. It uses Alternate Data Streams to store those metadata and view them in Explorer. Whenever files are copied/moved using TeraCopy, those  informations are lost as TeraCopy doesn't support copying Alternate Data Streams.

Another program named FileMarker uses ADS to store its custom File Icons.

I am sure a lot of softwares use ADS to store useful informations, so it will be helpful if you implement ADS copy feature in your popular program. Thank you.

Avatar
64
Code Sector
  • Planned
Avatar
38
Code Sector
  • Started
Avatar
19
swarup manna

Happy to see that ADS copy feature has been implemented in v3.7. It has also an option to save the file checksums into the alternate data streams while testing the source files, but lacking the feature to verify the checksums from already written streams. Kindly consider this if possible. Thank you...

Requested Feature Screenshot:

Avatar
17
Code Sector
  • Completed

TeraCopy already verifies checksums from streams, you will see two checksums for each file and an error message if those checksums mismatch. We will change the wording of this option.

Avatar
17
swarup manna

My apologies. Teracopy 3.7 does verify checksums from streams. But in the UI, the Result shows Testing:completed OK instead of Testing:completed Verified. Also, there is Single Green Tick instead of Double before each file in the 'File List' section. Whereas, if we test files with CRC32 in their filenames, Result shows Testing:completed Verified and Double Green Tick before each file in the File List.

Testing with Streams:

Testing with CRC32 in Filenames:

Avatar
swarup manna

In my testing I also find that...

1. Whenever Timestamp of a file(having checksum in stream) is changed without changing its content 

or,

2. Checksum in the stream is changed keeping the Timestamp same

and then testing with teracopy with "Save checksum to stream" enabled, it writes an additional entry to that checksum stream instead of updating and overwriting it. Screenshot attached..

1. Timestamp different, Checksum same...

2. Timestamp same, Checksum different...

My whole point to this is that you have maintained the Format of MD5Stream while writing checksum to the stream. So if only one entry(updating when required) is used instead of using double or more in a particular checksum stream, the whole thing remains compatible with the 'MD5Stream' program also.

By the way, as per my testing, the 'MD5Stream' conventions are like this...

* Correct: Stream present; no change in both 'MD5 Checksum' and in 'File Write Time'.
* Incorrect: Stream present; no change in 'File Write Time' but different 'MD5 Checksum'.
* Added: Stream absent. New 'MD5 Stream' added.
* Updated:
 1. Stream present; change in both 'File Write Time' and in 'MD5 Checksum'.
 2. Stream present; change in 'File Write Time', but no change in 'MD5 Checksum'.
* Invalid: Stream present; but invalid MD5 format and/or invalid File Write format.
* Inaccessible: File is corrupted to compute MD5 checksum.

Thank you for bearing with me...

Avatar
Code Sector
Quote from swarup manna

In my testing I also find that...

1. Whenever Timestamp of a file(having checksum in stream) is changed without changing its content 

or,

2. Checksum in the stream is changed keeping the Timestamp same

and then testing with teracopy with "Save checksum to stream" enabled, it writes an additional entry to that checksum stream instead of updating and overwriting it. Screenshot attached..

1. Timestamp different, Checksum same...

2. Timestamp same, Checksum different...

My whole point to this is that you have maintained the Format of MD5Stream while writing checksum to the stream. So if only one entry(updating when required) is used instead of using double or more in a particular checksum stream, the whole thing remains compatible with the 'MD5Stream' program also.

By the way, as per my testing, the 'MD5Stream' conventions are like this...

* Correct: Stream present; no change in both 'MD5 Checksum' and in 'File Write Time'.
* Incorrect: Stream present; no change in 'File Write Time' but different 'MD5 Checksum'.
* Added: Stream absent. New 'MD5 Stream' added.
* Updated:
 1. Stream present; change in both 'File Write Time' and in 'MD5 Checksum'.
 2. Stream present; change in 'File Write Time', but no change in 'MD5 Checksum'.
* Invalid: Stream present; but invalid MD5 format and/or invalid File Write format.
* Inaccessible: File is corrupted to compute MD5 checksum.

Thank you for bearing with me...

Thanks, we've fixed the multiple hash issue, please download the latest version.

Avatar
swarup manna
Quote from Code Sector

Thanks, we've fixed the multiple hash issue, please download the latest version.

Downloaded and tested v3.7.4. Problems related to multiple entries into the checksum stream have been resolved.

Many many thanks to the team for such a quick and fruitful update. Hats off to you guys.