iRecover suggestions

[Calab]

Just spent a couple days using iRecover. I didn't have much luck getting my data back, but none of the other programs I tried would work either, so it must just be too badly damaged.

I do have a few suggestions to improve iRecover though...

- During validation, iRecover needs to be able to validate more file types... especially important data types (.QDB = Quicken, .CDR = Corel, etc.)

- At the end of the process, when you are choosing files to restore, there needs to be more views than just the tree view. A "details" view similar to that in Windows Explorer, with the addition of a "folder" or "path" column and a "Valid/Invalid/Unknown" would be nice.

- The ability to "show only valid files" and "select all valid files" when choosing files to recover.

- When choosing which drives to include, show the drive serial number (or provide "Properties" for the drives.) Controllers aren't always numbered on the mainboard/controller in the same order as Windows sees them.

- When creating an image file, allow the file to be broken into smaller pieces, either set by the user or if the disk ends up full.

- Provide the user the ability to set more of the search paramters. For example, I know what order my drives should be, so let me specify that specifically.

- If a user has backups of some of the files, let the user provide those files to help determine the layout of the files/partitions/arrays.

- When in the Analysis stage, provide a "Step x of y" in the Current Operation area. Counting up to 100% a bunch of times doesn't help the user know how far into the process the analysis is.

- Let the user specify what RAID controller was used. This should help identify what parameters may have been used to create the array and how parity is stored, etc.

...anyhow, this is a great program. I appreciate the ability to try before I buy. Hopefully I won't need to try it again.  

[Joep]

Hello,

Many of your suggestions are valid and understandable. However also consider:

- memory consumption: On todays large disks and arrays we need every KB we can get. Adding even something as aimple as a listview (to mimic the explorer like view) will use up some of that memory. iRecover already tells you if a file was validated or not (green, red icon).

- validation: First of all, it must be possible to validate a file relatively easily, so the file must have a simple and known structure that is either intact or not. And the file also needs to be very common so we have a good chance of encountering it.

- show valid/unvalid: We can never tell for sure if a file is valid or not. Also, as you have noticed we can only sample a limited number of files. Therefore only showing valid files is as good as a useless feature. We would leave out 1000's of potential valid files.

- iRecover can only process complete image files (1 image file = one drive or disk) so storing them in pieces has no use.

- order of drives: Most users don't know this, so we opted for not including the option to eliminate guess-work. Each option you offer is a potential point of failure. Order of disk can and should be set if you provide array parameters manually (all of them, in device selection, right-click and select 'define array manually').

- I don't see how backups of some files can help us determine array or file system parameters. iRecover purely relies on NTFS structures for determining array parameters.

- Trouble with step n / m is that depending on the scenario steps and number of steps are different. So, step 2 of 4 isn't absolute.

- RAID controller: there are solutions that follow this road. We opted for determining parameters based on analysis. It's a design choice. We can't have both at the same time, how would we handle 'defaults' not ligning up with 'analysis'? The whole point of iRecover is that it figures out all parameters by itself. iRecover would need constant updating. We would need to monitor every possible RAID adapter all the time. We do not have resources for that. I can see if we can add an option to load array params etc. from some sort of config file. User community could then come up with config files for different RAID controllers. That meets your suggestion, and responsability for updating those config files is not with us.

So that's my considerations regarding your suggestions which I appreciate very much.