Welcome, Guest. Please login or register.
Did you miss your activation email?
June 19, 2019, 01:24:52 PM
Home Help Search Login Register
News:

+  DIY DataRecovery.nl Support forum
|-+  Support
| |-+  DiskPatch (Moderators: Tom, Joep)
| | |-+  Feature Requests: Smart Verify + Clone then Verify
0 Members and 1 Guest are viewing this topic. « previous next »
Pages: [1] Go Down Print
Author Topic: Feature Requests: Smart Verify + Clone then Verify  (Read 10979 times)
YPT
member

Posts: 8


« on: December 24, 2013, 05:14:23 AM »

First, thank you for the great, prompt, response/support.


Your time is limited so skipping to the meat of the matter, with the extra detail following...


1) Add option for "Clone then Verify."
2) Add option for "Smart Verify."


As it stands now, you must manually select Verify clone after acknowledging a successful clone; potentially wasting time.


The "Smart Verify" option simply attempts to recopy *only* the sector that didn't verify during the verify process.  Rather than abort, it then continues the verification process, taking only a few steps back from the sector that was recopied.


Had a weird Hitachi 40GB drive that seemed read troubled sectors with 100% accuracy on an individual basis using Disk Editor, but would corrupt specific ones during sequential reads.  I attempted to use Disk Editor to manually Export/Import those sectors between disks, but it seems the program deletes the clipboard and export data whenever you attempt to change disks.  So it eventually occurred to me to rerun the Clone process, targeting only those sectors that failed verification.  The scheme worked perfectly.  Fortunately there were only but three in total, Sectors 0, 2, and 29.  Sector 29 however stubbornly failed verification over and over; or it would pass verification then later fail again.  Huh  After noticing "DIY" in the sector data, it occurred to me that the program might be setting a marker; a site search later verified this.  Perhaps the verifier should notify the user about ignoring mismatches that involve "marked" sectors.  I lost at least 30-45 minutes repeatedly smashing my head up against the same issue.  Lips sealed


The idea came after reading this topic...
http://www.diydatarecovery.nl/forum/index.php/topic,1437.0.html
...and would've posted under that thread however that doesn't seem to be allowed; so created a new thread.


I have a version from 2011.  So forgive me if anything here has already been implemented.  I understand from another recent post, that GPT/GUID support has been implemented with the newest revision.  But so far I've not had issue performing disk related tasks on drives setup with GPT/GUID vs MBR.


There seem to be a lot of BIOS implementations that give the program issues.  Especially those that default to AHCI, RAID, don't have a clear cut legacy mode for the drive controller, don't fully support USB drives,  or/and have security features implemented such as "Secure Boot." Fortunately I have an old Desktop with IDE & SATA-I (nVidia chipset) that comes in handy for this. 

Keep up the good work...
Logged
Tom
Developer and Support Tech
Administrator
member
*****
Posts: 1476


WWW
« Reply #1 on: December 24, 2013, 11:19:55 AM »

Quote
I attempted to use Disk Editor to manually Export/Import those sectors between disks, but it seems the program deletes the clipboard and export data whenever you attempt to change disks.
No it doesn't. Export files are connected to disk numbers, by using the disk number as the extension.
Quote
The scheme worked perfectly.  Fortunately there were only but three in total, Sectors 0, 2, and 29.  Sector 29 however stubbornly failed verification over and over; or it would pass verification then later fail again.
This is to be expected, these sectors are used by DiskPatch during the clone process. These sectors are of no importance to the data on the target disk, which is why they are used for clone data. You can safely skip cloning these sectors, and sector 0 and 2 are cloned by DiskPatch when the clone process completes.
Quote
Perhaps the verifier should notify the user about ignoring mismatches that involve "marked" sectors.  I lost at least 30-45 minutes repeatedly smashing my head up against the same issue.
During a normal clone session this is not an issue. Only when running the verify again after the whole clone process is completed, this could prop up. This is by design; once a clone has completed it should be left alone (DiskPatch uses hidden sectors on a disk for keeping records, this is explained in the manual). By working with the cloned disk you effectively change the contents of the disk, so the clone results are essentially invalidated. This is a forensic way of thinking, and as stated, by design.
Quote
I understand from another recent post, that GPT/GUID support has been implemented with the newest revision.
No it hasn't. We recognize GUID data on a disk and take appropriate actions before attempting repairs, but at this time we do not repair GUID volumes.
Logged

YPT
member

Posts: 8


« Reply #2 on: December 25, 2013, 03:27:23 PM »

Quote
No it doesn't. Export files are connected to disk numbers, by using the disk number as the extension.
There is no option to browse files in the program; nor is the extension displayed when saving the file.  

So you mean to say that entering the file name plus disk number loads the file; for example "000000D1.002" if this is Disk 2, or "000000D1.000" if the source disk is Disk 0 ?

Clipboard data DEFINITELY is cleared by the way.

Quote
This is to be expected, these sectors are used by DiskPatch during the clone process. These sectors are of no importance to the data on the target disk, which is why they are used for clone data. You can safely skip cloning these sectors, and sector 0 and 2 are cloned by DiskPatch when the clone process completes.
This is the search phrase and page that I had used to confirm that observation prior to posting my recommendation.
https://www.google.com/#q=site:diydatarecovery.nl+sector+29
http://www.diydatarecovery.nl/FAQ_diskpatch.htm
The FAQ was titled for a different problem however; nothing to do with failed verifications.  Regardless it did confirm my observations about what it was doing.

Quote
During a normal clone session this is not an issue. Only when running the verify again after the whole clone process is completed, this could prop up. This is by design; once a clone has completed it should be left alone (DiskPatch uses hidden sectors on a disk for keeping records, this is explained in the manual). By working with the cloned disk you effectively change the contents of the disk, so the clone results are essentially invalidated. This is a forensic way of thinking, and as stated, by design.
Actually this fails "forensics" protocol.  The only function that was employed by "I," was CLONE and VERIFY.  Therefore *I* did not "change the contents of the disk."  The program however, did modify the disk.  

The recommendation still stands, "... the verifier should notify the user about ignoring mismatches that involve 'marked' sectors."  I shouldn't have to search the manual when this potentially comes into play with every use of the verifier.  If you're using something other than clone & verify, I can understand the behavior as something other than "marking."
Logged
YPT
member

Posts: 8


« Reply #3 on: December 25, 2013, 03:33:07 PM »

Quote
No it hasn't. We recognize GUID data on a disk and take appropriate actions before attempting repairs, but at this time we do not repair GUID volumes.
THanks for the extra information.  However I never use DiskPatch to repair data structures; only recover the drive and/or it's content.  Are these functions compromised in any way under the older revisions ?
Logged
YPT
member

Posts: 8


« Reply #4 on: December 25, 2013, 03:46:04 PM »

Additional request:

The verifier should give the option to continue after encountering the first mismatch.
It should be easy to include a count of the number of mismatches.
Not as easy, is including a log of each sector that failed mismatch.

If there is a small set of sectors that failed verification, then it makes sense to just go back and re-clone those individual sectors.  However if there are a large set of mismatches, then some other action may prove prudent.  In other words, for some situations, it may help to know the level of corruption that occurred during the clone.

Thanks again.
Logged
Tom
Developer and Support Tech
Administrator
member
*****
Posts: 1476


WWW
« Reply #5 on: December 25, 2013, 08:19:21 PM »

Just FYI, the clone function was overhauled earlier this year, check the version history in the ReadMe file.

The verify thing... You do have a point there but there is another issue. When a clone is done on a bad disk there is no telling what sectors will do during and after the read. Once a clone is finished it is entirely possible that, when doing a new read across the original disk, sectors behave differently. The verify function is meant to only tell you that the clone is either perfect, or that it is not. Verifying a clone from a bad disk is tricky business anyway, because of what I said above.
Re-cloning sectors is a feature we've been contemplating but it doesn't make a lot of sense in the context of the current 2-step clone.

All read errors and clone failures are logged, if you so desire.

There is something to be said for not aborting the verify and reporting results afterwards, I'll have a look at that, think about it. Maybe a toggle/feature.

Understand that you can at any time re-start the clone, so you can re-do bits that you believe were missed altogether (use the log to find the locations).

I'll also have a look at the data sector clone/verify issue. Perhaps I can make that a little more elegant...
Quote
If there is a small set of sectors that failed verification, then it makes sense to just go back and re-clone those individual sectors.  However if there are a large set of mismatches, then some other action may prove prudent.  In other words, for some situations, it may help to know the level of corruption that occurred during the clone.
The details of the clone are in the log. Perhaps this info isn't easy to read, but it is there. I suppose you're looking for a nicer presentation of the problems during the process, or perhaps a clone report that gives detailed info in more digestible way.
Logged

Pages: [1] Go Up Print 
« previous next »
Jump to:  


Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!