DE-Storage Compressed Format Glitches

[DataMedics]

So I've been playing around with the new DE-Storage format, running a few cases with it and I'm finding some glitches. The speed issue I earlier reported seems to have been resolved by upgrading my CPU to a $1000 Ryzen Threadripper with 16 cores, so that's better now.

One glitch I've found is that you can only have one DE-Storage task open in each instance at a time. Otherwise, it gives an error about being out of memory (which can't be true I've got 32Gb). So I can't have one task open for imaging and also open another task to copy some files or check something.

Another glitch, which has me confounded, just happened today. I had a task that was 100% imaged with no bad sectors. It was from a DVR so it was a 100% full disk beginning to end. The customer wanted a clone drive, so I did a data export to another drive to provide the client. It got to 99.99% (actually looks like it finished) then spit out a bunch of IO errors regarding the source. I checked the target/destination drive and only about 20% of the data even copied. So for 80% of the time it was just pretending to write data, or was just writing zeros instead of writing the actual data.

I think this format needs a bit more testing.

[Nick_TS]

Hello Jared,

Source of the post One glitch I've found is that you can only have one DE-Storage task open in each instance at a time. Otherwise, it gives an error about being out of memory (which can't be true I've got 32Gb).

Data Extractor has x32 Kernel, so it can use 3.5Gb of RAM only.

Source of the post Another glitch, which has me confounded, just happened today. I had a task that was 100% imaged with no bad sectors. It was from a DVR so it was a 100% full disk beginning to end. The customer wanted a clone drive, so I did a data export to another drive to provide the client. It got to 99.99% (actually looks like it finished) then spit out a bunch of IO errors regarding the source. I checked the target/destination drive and only about 20% of the data even copied. So for 80% of the time it was just pretending to write data, or was just writing zeros instead of writing the actual data.

This bug will be fixed in new version.

[Amarbir[CDR-Labs]]

Source of the post Hello Jared,

Source of the post One glitch I've found is that you can only have one DE-Storage task open in each instance at a time. Otherwise, it gives an error about being out of memory (which can't be true I've got 32Gb).

Data Extractor has x32 Kernel, so it can use 3.5Gb of RAM only.

Source of the post Another glitch, which has me confounded, just happened today. I had a task that was 100% imaged with no bad sectors. It was from a DVR so it was a 100% full disk beginning to end. The customer wanted a clone drive, so I did a data export to another drive to provide the client. It got to 99.99% (actually looks like it finished) then spit out a bunch of IO errors regarding the source. I checked the target/destination drive and only about 20% of the data even copied. So for 80% of the time it was just pretending to write data, or was just writing zeros instead of writing the actual data.

This bug will be fixed in new version.

Sir ,
I have my own opinion that some bugs should be fixed at lightning speed and all active TS users should be updated with it ,Some bugs are serious to be ignored

[Nick_TS]

Source of the post all active TS users should be updated with it ,Some bugs are serious to be ignored

All serious bugs are fixed free for users. And all users are updated with it.

Source of the post I have my own opinion that some bugs should be fixed at lightning speed

Some bugs require time for detecting and fixing. It's longtime and complex process.