Recovery Force® Data Recovery Forum

Feature Requests:

1. Make imaging functions a little more intuitive (ie, Menu Button to Image, choose source, choose destination, etc)
2. Multiple pass imaging for better handling of drives with bad sectors
3. Prompt to add DeepSpar project ID when one isn't already set
4. Add option to lock DeepSpar Activity monitor and/or Terminal on top of other application windows
5. On file duplicate message, add option to keep most recent
6. When interfacing with DDI, PC3000 or MRT map files, allow a way to verify files and generate an HTML report showing the good and damaged without having to first save them to a destination drive. Even if we had to save to separate HTML files, one for the good and one for the damaged, that would be fine.
7. Allow the user to select targeted data within a bitlocker/core storage volume and still push to background image with DDI (refer to this post for more details - viewtopic.php?f=42&t=654)\
8. Configure to handle imaged drives with the MBR disabled (55AA set to 55BB at the end of sector 0) and the EFI disabled (EFI set to XFI at the beginning of sector 1)

Glitches:

1. Imaging to file on linux (possibly with other versions), can result in the last block of sectors being marked as bad. Seems to be if the last block to be read is smaller than the block size reading (ie, 512 sectors to read, but reading 4096). The result is the image file is larger than the source and the actual blocks that should have been read at the end of the drive, get written as damaged, without the original content.

Hi

A save progress system in case of a system crash or power failure.

1. Make imaging functions a little more intuitive (ie, Menu Button to Image, choose source, choose destination, etc)

Currently imaging function can be invoked from:
- disk/partition context menu;
- select disk, then click button on toolbar above disks;
- open disk (advanced) with "for imaging" task selection;
- from explorer (with map).
I don't think that additional "wizard" will simplify this or will make this more obvious.

2. Multiple pass imaging for better handling of drives with bad sectors

Currently there are two passes. When you are imaging to SDLSP file, there is option to reset defects and re-image them again.

3. Identify a partition table, even if MBR is disabled with 55BB or another pattern

55BB is supported for very long time. "DEAD" in LVM and "XFI PART" in GPT are supported since 8.10.

4. Prompt to add DeepSpar project ID when one isn't already set

TODO: we will check if this possible.

5. Add option to lock DeepSpar Activity monitor and/or Terminal on top of other application windows

This is not possible in current cross-platform SDK. Possibly to consider this in the future.

6. On file duplicate message, add option to keep most recent

Do you mean "the one with most recent modification date"?

7. When interfacing with DDI, PC3000 or MRT map files, allow a way to verify files and generate an HTML report showing the good and damaged without having to first save them to a destination drive. Even if we had to save to separate HTML files, one for the good and one for the damaged, that would be fine.

This option will be added in later software versions.

8. Allow the user to select targeted data within a bitlocker/core storage volume and still push to background image with DDI (refer to this post for more details - viewtopic.php?f=42&t=654)

BitLocker and CoreStorage re-translate addresses. This means every sector defined by files map have to be re-translated to different (traslated) map. This require lots of work to make it work efficiently so this can be possible in later releases.

"Glitches":

1. Imaging to file on linux (possibly with other versions), can result in the last block of sectors being marked as bad. Seems to be if the last block to be read is smaller than the block size reading (ie, 512 sectors to read, but reading 4096). The result is the image file is larger than the source and the actual blocks that should have been read at the end of the drive, get written as damaged, without the original content.

When size of storage in 512b blocks will be not multiple of 8, the software will assume 512b imaging by default (will be available in 8.11).

2. Configure to handle imaged drives with the MBR disabled (55AA set to 55BB at the end of sector 0) and the EFI disabled (EFI set to XFI at the beginning of sector 1)

Is this about support of these images? 55BB is supported for a long time, while "XFI " is supported since 8.10
Also, this is not "glitch", this is "feature request"

pclab wrote: ↑Tue Dec 08, 2020 8:55 pm Hi

A save progress system in case of a system crash or power failure.

- it is already in "TODO" list at low priority.
Planned function is to set up "Save state automatically every NN minutes" on "start scan" page. This will be implementation of automatic pausing/saving state/resuming.

sdl wrote: ↑Wed Dec 23, 2020 10:06 pm

2. Multiple pass imaging for better handling of drives with bad sectors

Currently there are two passes. When you are imaging to SDLSP file, there is option to reset defects and re-image them again.

Okay, good to know. Any chance of having that function added to drive-to-drive imaging? If we have a 3TB drive to work with and have to clone the entire drive, it is better to clone drive-to-drive rather than need a larger formatted drive to hold the SDLSP file.

sdl wrote: ↑Wed Dec 23, 2020 10:06 pm

3. Identify a partition table, even if MBR is disabled with 55BB or another pattern

55BB is supported for very long time. "DEAD" in LVM and "XFI PART" in GPT are supported since 8.10.

Great! Thanks.

sdl wrote: ↑Wed Dec 23, 2020 10:06 pm

4. Prompt to add DeepSpar project ID when one isn't already set

TODO: we will check if this possible.

Great! Thanks

sdl wrote: ↑Wed Dec 23, 2020 10:06 pm

6. On file duplicate message, add option to keep most recent

Do you mean "the one with most recent modification date"?

That is correct.

sdl wrote: ↑Wed Dec 23, 2020 10:06 pm

7. When interfacing with DDI, PC3000 or MRT map files, allow a way to verify files and generate an HTML report showing the good and damaged without having to first save them to a destination drive. Even if we had to save to separate HTML files, one for the good and one for the damaged, that would be fine.

This option will be added in later software versions.

Awesome!

sdl wrote: ↑Wed Dec 23, 2020 10:06 pm

1. Imaging to file on linux (possibly with other versions), can result in the last block of sectors being marked as bad. Seems to be if the last block to be read is smaller than the block size reading (ie, 512 sectors to read, but reading 4096). The result is the image file is larger than the source and the actual blocks that should have been read at the end of the drive, get written as damaged, without the original content.

When size of storage in 512b blocks will be not multiple of 8, the software will assume 512b imaging by default (will be available in 8.11).

Yes, that makes sense.

Thanks for taking the time to respond. I think I'm safe to say on behalf of all the data recovery professionals using UFS Explorer, we really appreciate how you not only take the time to respond to our requests, you actually take them into consideration and incorporate many of them.

BTW I hate that, how UFS does this offset to partition in LBA, size in MB.



Either do BOTH in MB or both in LBA.

In this specific location (assuming you are about list of partitions on the left side), more informative to display size in MB/GB/TB. Why? Because one usually tells "that 3TB partiton", and not "that partition with max.LBA 6291455999".

Offset like 2048/63/etc. (in sectors) is much more informative than "0.0MB".

That is just effient using of limited space for usability and not for "visual perfection".

If you want to see "straight unified values" , you may switch to "properties" sheet.

In this specific location (assuming you are about list of partitions on the left side),

Yes.

more informative to display size in MB/GB/TB. Why? Because one usually tells "that 3TB partiton", and not "that partition with max.LBA 6291455999".

Same can be argued someone telling a partition starting 200 GB into the drive is easier and more likely than someone giving you LBA address. Yes, end user may probably use MB/GB but that's not the point. I want to be able to tell, quickly without having to do conversions if partitions make sense.

Offset like 2048/63/etc. (in sectors) is much more informative than "0.0MB".

No, see previous point.

That is just effient using of limited space for usability and not for "visual perfection".

That's a nonsense argument. LBA numbers will fit easily there unless you have a tiny screen

If you want to see "straight unified values" , you may switch to "properties" sheet.

I want unified numbers there, in that specific spot, that's why I ask. I want unified numbers with all partitions in sight, in eagle eye view.

Joep wrote: ↑Sun Jan 03, 2021 10:31 am Same can be argued someone telling a partition starting 200 GB into the drive is easier and more likely than someone giving you LBA address.

In most cases partitions are in ascending order, so "200GB offset" is easily seen from preceding partition(s) size.

Joep wrote: ↑Sun Jan 03, 2021 10:31 am That's a nonsense argument. LBA numbers will fit easily there unless you have a tiny screen

1) This is "nonsense" if you replace MB/GB/TB with LBA. If you show both (LBA+MB/GB/TB) - this will take much more space.
2) This replacement (user-readable size to LBA), as it was said before, is "nonsense".

It's possible to consider user customization of these columns in the future ("as is", "both LBA format", "both in human-readable format").
For now, I'd like to stop this discussion at this point for "flood prevention reasons".
Thank you.

lcoughey wrote: ↑Tue Dec 08, 2020 6:30 pm

1. Imaging to file on linux (possibly with other versions), can result in the last block of sectors being marked as bad. Seems to be if the last block to be read is smaller than the block size reading (ie, 512 sectors to read, but reading 4096). The result is the image file is larger than the source and the actual blocks that should have been read at the end of the drive, get written as damaged, without the original content.

- solution for this request is currently "live" and be checked.