| Author | Message | ||
     Softscope |
My initial reason to purchase Winhex was the need for a simple hex editor. Afterwards I had a few occasions where I cloned a drive just to be sure. But generally I stayed with the backup system of Windows 2000, because with system related issues you often need a merging of the existing data with a backup. For problems related to the system drive, it is often mandatory that you use a backup to get back a running system, like when you change the mainboard. However, when the problem is hardware related it often would be a lot simpler just to have an image of the drive. I have run into that situation once or twice now. My question is: Can I do this automatically? There comes a sample script file with Winhex that seems to show how powerful the script language is, but I just need a command that says: Make an image of drive c: to file x:\filename. I wouldn't dare just to test the script language, only to find out after one or two days that I have ruined the original drive. Another question is: Would this work with a running system? Regular backups can only be made with the system running. For cloning I have put the respective drives in a different PC, but for a backup the system must be running with services accessing files. And a last question is: Do I have a chance to mimick the way the different types of backups are made? As full backups (and imaging as well) take a long time, full backups are only made starting at night on weekends, while only incremental backups are made at night during the week. Yet this is only an informational question, because file attributes could also be set in a batch file. | ||
| Stefan Fleischmann (Admin) |
The commands you are looking for are Open C: Assign EndOfDisk GetSize Dec EndOfDisk Block 0 EndOfDisk CopyIntoNewFile x:\filename I wouldn't recommend imaging the C: drive with the active, running Windows system, as the image may have an inconsistent state. WinHex is only capable of doing sector-wise, exact backups and images. For incremental backups that respect file attributes, file times, etc. you cannot use WinHex. This is outside the scope of the software. | ||
| Softscope |
Thanks for the info. I didn't mean to make incremental backups with Winhex, just to combine them with Winhex. I think the simplest way ist to have a batch file making the image, and add a line with 'attrib -A d:\*.* /S/D'. This will reset the archive bit on all files. If an incremental backup is run each day, I will have on Saturday an image from last Sunday plus an incremental backup of those files that have the archive bit set since then. Re archiving the system drive: Sorry if I sound dumb, but I Just want to make sure I got the info on the website right. Winhex is a true Windows application, is it? To make images of the system drive without taking the disk out I would have to upgrade to the specialist license and could then pull images by starting from a DOS floppy, using X-Ways Replica. Did I get that right? Actually, getting back a stable system drive is more crucial than data disk problems. And with NTBackup you have to create a new Windows 2000 on the drive, and then run a Restore against it. In good MS fashion, the Restore tends to make a mess of this. I was afraid you couldn't make an image of a running Windows system, so I never tried it. But shutting down the system, making the image from DOS, and then restarting is a good option. I hope if I create a partition on the backup drives of the exact size of the system drive, I can clone into that partition. | ||
| Stefan Fleischmann (Admin) |
Yes, WinHex is a Windows-only application. X-Ways Replica currently can only clone from one disk to another (and yes, one partition to another on another disk), and cannot create an image file. | ||
| rjohnson |
Is this the correct forum for Replica? I have a Specialist License and have used Replica just a few of times (v.94 as of now), when a drive with sector errors is the source and an error occurs from that drive a choice is offered, If I remember correctly it goes something like this, '(i)gnore, (a)bort, al(w)ays ignore' if I press 'i' it seems to ignore and continue (however, there is no real status indicator such as a rolling 'X') but what I would really like to do is always ignore, but the 'w' key press seems to result in no action. I have just recently tried v.94 on an HD where I know exactly where the few bad sectors are (78-87 on this HD), the menu came up at the right sector (78), I pressed 'w' and waited too long, no visual response, stoppped the job, looked at the destination and nothing was on it, not even sectors 0-77 (I had zero'd the destination drive ahead of time) I thought that was very odd unless Replica transfers a bunch of sectors to RAM before sending to the destination? Every time I have used the 'w' key it has never really continued like it does when I do it manually with the 'i' key. Is the 'w' the correct key? Does it need to be CAPs? Was there a language translation error? When the 'al(w)ays' option works will it spend less time retrying each bad sector before ignoring or is the number of retries a DOS thing? Can it be a command line option to vary the retries. As always, thank you very much for a great product!!! | ||
| Stefan Fleischmann (Admin) |
I will have to check that "w" option and let you know here. Yes, Replica usually does not transfer each sector individually, that would be inefficient. The number of retries in case of bad sectors will remain the same (1) even after pressing "w". | ||
| rjohnson |
Thank you for your fast response. It is possible then that the program was working correctly and perhaps found another set of bad sectors that it stalled at (I mean a drive with known bad sectors can't be expected to be perfect, I will check). would it be possibel to add a "current sector being read" display? How much does it read before writing to the destination? I prefer the low number of retries (1) thanks, is that read request (number of retries) being sent at a high enough level that the Hard Drive controller will still be performing its built in number of retries per sector read request or are the sector read requests at the lowest (most direct) level to minimize retries to the lowest possible count? I have purchased plenty of good (DOS & Windows)sector copying (drive imaging) software that can copy healthy drives at high speed but when it comes to unhealthy drives they vary dramatically in how much time they spend on bad sectors (retrying). Since bad sectors are indicative of a failing drive, I am looking for a sector copying program (DOS) that can intelligently minimize access to trouble areas (possibly an option to skip a fixed amount of sectors when errors occur, maybe even logged back to the screen, lpt1 or a floppy) the idea is to grab as much of the healthy area as possible while the drive is still running (any drive can go down at any time) then go back for bad areas later. Drives with relatively few bad sectors would benefit dramtically and this would also help to cut down on clean room demand. Thank you again and I understand that there are limits to your time. | ||
| Stefan Fleischmann (Admin) |
I confirm that the "ignore al(w)ays" option (lower-case "w") did not work in v0.94 of X-Ways Replica. This is now fixed with v0.95. Please download again. > would it be possibel to add a "current sector being read" display? The current display should be sufficient (sector that has just been copied). > How much does it read before writing to the destination? 96 sectors > at a high enough level Yes. > intelligently minimize access to trouble areas Would be useful, will keep your suggestion on file, thanks. | ||
| rjohnson |
Thank you very much for the quick fix! the 'w' key now works. Replica worked well skipping the errors. The 'current sector being read' question arose because during the source read (with sector errors in the first 96 sectors), nothing was being displayed to indicate progress, so if there are 50+ bad sectors at the front of the drive it may be awhile until the first display of progress shows on screen (depending on hardware specs like drive speed, controller card speed). Using the (i)gnore option will at least display the bad sector number which indicates the sector being read is known to the program. I am just not sure if the error menu is displayed instantly when a sector error occurs or only after the current block of 96 sectors has been read (or attempted to be read). I agree that this DOS approach is more forensically sound but some 'evidence' hard drives do have a number of unreadable sectors, it would be unwise to not have that information documented or logged (i.e. which source sectors were skipped and were they replaced with zeros on the destination) to do this manually on say just 1,000 randomly located bad sectors would easily add an hour of copy time at 2.5 seconds per bad sector (on high speed equipment with contemporary hard drive). 1,000 bad sectors out of 120 million might be unimportant for standard data/file recovery but for evidence use, a good prosecuter/defender could invalidate the whole drive if quantity and location of missing potential evidence is unknown! If it happens to be 100,000 bad sectors out of 120 million it is still relatively small but would require hours of manually monitoring Replica and writing down each displayed bad sector (using the 'i' option). My statements may induce those who have lost a civil or criminal case, where Replica was used to gather evidence against them, to have the case against them revisited if the verdict was primarily derived from that gathered evidence. Of course, any drive with physical problems (i.e. mechanical/electrical) that is needed as evidence is headed to the clean room (and 'chain of custody'), however, it is possible for a drive to be mechanically and electrically sound but the media surface no longer retains some data (e.g. sector header/footer info) and a clean room will not help, therefore a powerful, high speed program like Replica (with logging added) becomes very valuable. This lost evidence (i.e. gaps in evidence) must be logged. Conversely, if the drive is completely healthy (i.e. there are no sector errors) that must also be logged as this helps to validate the strength of the evidence. If Replica is being used to gather evidence from a hard drive then the tech is likely replicating the whole drive. But if one is gathering just a single partition from a drive as evidence it would be wise to display on the screen (and/or log file) the physical sector range being copied from the source (in addtion to the already included hard drive number and partition number of the source). There are too many methods to list here that can alter a partition table in an instant to point to different starting sectors, it is crucial for the evidence to withstand scrutiny and therefore the gatherer must be able to say with accuracy and confidence exactly where the evidence came from (without a doubt). I would like to thank Stefan again (and any others involved in the program development) for the hard work and rapid response. This is already great software that just keeps getting better (no one is resting on their laurels). | ||
| Stefan Fleischmann (Admin) |
The error menu is displayed when an attempt to read a block of 96 sector has failed, and reading the first sector of it individually has failed, too. I will most probably add the same capability to X-Ways Replica as WinHex already has, that is, to write a complete log file about the cloning process: date+time started, source disk and start sector, destination disk and start sector, number of sectors to copy, list of sectors that could not be copied, and number of sectors that were successfully copied. | ||
| rjohnson |
Thank you very very much! An extremely helpful option for Replica would be to choose on the source drive a start sector (and length in sectors). Thank you again. | ||
| Stefan Fleischmann (Admin) |
X-Ways Replica 1.0 is now capable of writing a complete log file. | ||
| Stefan Fleischmann (Admin) |
X-Ways Replica 1.2 will finally be able to create image files with segments of any size (e.g. on FAT16: 2048 MB). | ||
| rjohnson |
The 'skip range' in the Clone Tool is helpful to have and does improve speed in many situations, but I suspect that the read ahead buffer still affects the results? I am assuming that the 'skip' will prevent subsequent explicit attempts to read the specific sectors and thus avoiding additional 'read aheads' during those attempts, but the first attempt at a bad sector still may have some additional sectors to read into the buffer and if they also are bad sectors then there will still be some delay for that process to finish? I am processing an HD that has a specific pattern of 16 bad sectors contiguously (whenever a bad sector is encountered), I have sector tools that read single sector mode (no read ahead) that can touch and tell a bad sector quickly, allowing me to manually jump ahead, but it would be great to have the option to toggle 'single sector read' mode included in WinHex for times like this. I know you have mentioned that the Data interpreter would be adversely affected by such a toggle option, but I truly believe that if one were in need of single sector mode for awhile, the time saved would easily make up for the imbalance. While cloning, the Data Interpreter would have low use. While manually scrolling/browsing, some conflict could arise, but a 'specialist licensee' could handle that. Thanks for reading this. | ||
| Stefan Fleischmann (Admin) |
> I suspect that the read ahead buffer still > affects the results? No, when a read error occurs, WinHex chooses to read sectors one by one in order to maximize the amount of successfully retrieved data. The "skip" option with e.g. 25 sectors would hardly make sense if WinHex were still to read thousands of sectors at a time anyway. > it would be great to have the option to toggle > 'single sector read' mode included in WinHex for > times like this The mode switches in a fully automated way. > I know you have mentioned that the Data interpreter > would be adversely affected by such a toggle option No. In WinHex, read access necessary for disk cloning is not related to (totally independent from) read access necessary for normal operation, sector display in edit windows, and the Data Interpreter. | ||
| rjohnson |
Thank you for the clarification above. New question: Here is a sample snipit from a clone log. 1,629,599 1,629,600..1,631,295 skipped. 1,961,055 1,961,056..1,963,071 skipped. 2/21/2004, 09:48:34 984,345 sector(s) copied. 15,648 skipped. 7 bad source sectors encountered. Fill with: 0x00 --- *** --- I do not have 'write pattern for damaged source sectors' checked, but 'Fill with: 0x00' is in the log. I have confirmed that destination sectors that once had data have been overwritten with zeros including 'skipped'. Is there some other switch I need to set? It appears that the skip number is not strictly enforced, when I set '8000' as the skip number, the log indicates 4607 or therabouts are skipped, I checked Hex vs Dec settings but that does not explain the difference, is it something else? Wish list items: 1. 'View Log' button in the Clone dialog box (or tool bar), allowing quick access in order to review most recent work. 2. Possibly leaving the Clone dialog box open (or facsimile thereof)while the cloning proceeds, to retain a visible reference to the current settings in use. Thank you. | ||
| Stefan Fleischmann (Admin) |
> 'Fill with: 0x00' is in the log The log is incorrect, there, unfortunately. This line should not be there with the settings you have used. Will be fixed with the next release. > I have confirmed that destination sectors that > once had data have been overwritten with zeros > including 'skipped'. That I tried to reproduce, but can't, so I still think that it works correctly, and the corresponding destination sectors are not filled with the pattern. > when I set '8000' as the skip number, the log > indicates 4607 or therabouts are skipped 4607 is the maximum number of sectors that can be skipped because after that number of sectors WinHex tries to return to normal mode instead of single-sector mode. | ||
| rjohnson |
Thank you, that helps clarify. How about this: ----------------------------------- 2/21/2004, 15:06:38 Hard disk 1 -> [C:\whclone\test.000] Sector 62,000,000 -> Sector 62,000,000 58,000,000 Sectors Sectors that could not be read: 62,000,000 62,000,001..62,004,607 skipped. 62,004,608 62,004,609..62,009,215 skipped. 62,009,216 62,009,217..62,013,823 skipped. 62,013,824 62,013,825..62,018,431 skipped. 2/20/2004, 05:11:27 4,607 sector(s) copied. 18,428 skipped. 4 bad source sectors encountered. Fill with: 0x00 ------------------- I aborted this one, and it did not appear to write to the destination beyond sector 62,018,431, but the process does not clarify that. It would be helpful for the log to say 'user abort - last destination sector written 62,018,431 ". Was 4,607 copied at the end? BTW, note the destination, could that be the cause of overwrites mentioned in the previous message? (I know it is different, but it works great for me in specific situations, thanks for the options!) Thanks again. | ||
| Stefan Fleischmann (Admin) |
4,607 sectors were copied, 18,428 were skipped, 4 were bad, so 23,039 sectors were processed in total (in the sense of either transferred where possible or else not transferred), sectors 62,000,000 through 62,023,038. > it did not appear to write to the > destination beyond sector 62,018,431 No? According to the log file, it did. > but the process does not clarify that The log file clarifies that. It mentions all the basic figures, so you can calculate whatever you need to know further. It just does not make sense to list all theoretically possible values and recombinations such as last sector read, last sector written, last bad sector, last skipped sector, destination sector corresponding to last bad sector, destination sector corresponding to last skipped sector, destination sector corresponding to last sector processed on source disk, etc., in particular since "last sector written" is not clear about whether "written with source sector data" or "written with byte pattern". > It would be helpful for the log to say > 'user abort - last destination sector written 62,018,431 That would be incorrect. 62,018,431 was the destination sector corresponding to the last skipped sector. If you need to know this number, sorry, please calculate yourself. > Was 4,607 copied at the end? I am not sure I understand the question. > note the destination, could that be the cause > of overwrites mentioned in the previous message? No, I don't think so. | ||
| rjohnson |
CONFIRMED OVERWRITES IN CLONE TOOL I have tested and confirmed! WinHex 11.25sr7 DOES overwrite the the destination with zeroes for up to 512 sectors under various conditions. I am attempting to test for all variables but for now here are at least some tested/proven factors and variables to allow others to verify/reproduce: 1. Use source with known bad sectors (unreadable) 2. include bad sector(s) in source selection 3. set range high enough to include sectors queued to clone beyond the abort point. 4. have test destination with known fill pattern 5. abort while bad sectors are attempting to be read. 6. wait for WinHex to respond to abort (e.g. no reboot or CTRL-ALT-DEL) 7. verify destination fill pattern against the log report. basically try to find the last sector written (this you will have to 'calculate yourself' as per this forum) you will find up to 512 sectors of zeroes beyond the aborted sector!! If in doubt, start clone on a known bad source sector that is followed by good sectors with random data, set range to 200, abort ASAP, WinHex will state 199 sectors copied, you will find 199 zeroed sectors on the destination overwritting the fill pattern rather than the expected clone of the random data or the fill pattern, and if the destination had already contained data in that range, it is now gone! in short, an abort while reading bad sectors will cause an overwrite of up to 512 sectors on the destination (less if the remaining range is less, at which point it will overwrite [zero] 1 more sector than the remaing range) You can unknowingly overwrite (zero) up to 256k per abort. If you are creating/patching the destination together by making multiple clone attempts of various ranges on the source (and some ranges happen to be close to each other) and aborting upon bad sectors you will be at extreme risk of zeroing up to 512 sectors of prevous work. have not tested with earlier versions of Winhex, unknown if previous work is tainted - This information should be considered CRITICALL in importance to forensic investigators and professional recovery services. Please consider this an important issue worthy of further investigation as I am unable to test all versions and all variables in a timely manor and still maintain my normal workload as an enduser of this tool. (I have lost over a day of work confirming this when I took your advice to "calculate yourself" and found to many discrepencies). | ||
| Stefan Fleischmann (Admin) |
I have to confirm that the abort procedure was not clean during the handling of bad sectors. Reading from the source disk was aborted earlier that writing to the destination disk was. This is now fixed with WinHex 11.25 SR-8. I'm very sorry for the time you spent on this. The log file issue from above is fixed as well, and the log file now does indicate user abort. | ||
| rjohnson |
Thank you. Two wish list items: 1. clone in reverse. This may seem like an odd request, but I see real value in it. The ability to clone a range from high LBA to low LBA, perhaps just by using a negative range number. 2. open a physical device at an optional sector (bypassing sector 0). Is this allowed with hard drives? If so, this would speed re-entry to HDs found to have a bad MBR. Thank you. | ||
| Mike Montgomery (Mikem22) |
You can acheive reverse cloning using the built in scripting tool in the pro version. Mike | ||
| Mike Montgomery (Mikem22) |
Addition to above.. Reverse cloning is considerably slower than forward cloning because the read ahead cache becomes redundant. | ||
| rjohnson |
Thanks Mike, Do you have a sample script? I do not see a script command or option that will reverse clone. I do see that I could select small blocks starting at a high LBA, copy, decrement LBA block, repeat. If that is what you meant by slow, I agree. Search Up has proven very effective in certain situations where All or Down are limited. In those same situations a Clone Up or reverse would also be better than a normal clone. If this is already available in scripting that should be suitable. Would "Block 999999 0 CopyIntoNewFile c:\reverseclone" work? Hey, thanks again Mike. | ||
| Stefan Fleischmann (Admin) |
> If this is already available in scripting that should be suitable. No, it isn't. > Would "Block 999999 0 CopyIntoNewFile c:\reverseclone" work? No, a block has no direction and always needs to be specified like Block LowerLimit UpperLimit. | ||
| Mike Montgomery (Mikem22) |
I dont have a script as such but and your assumption is correct, read-decrement, write-decrement. I guess it would go something like this. //Start open 81h read only //Source move 'to end of drive in bytes - 512 bytes' open 82h in place //target move 'to end of drive in bytes - 512 bytes' { nextobj //81h read aBlock 512 // read 512 bytes from 81h move -1024 //go back 2 sectors nextobj //82h write ablock // write it to 82h move -1024 } [number of sectors in LBA] //End The reason for moving back 1024 is that the read 'x' will change the position of the drive to x+512 so to get back to x you need to move -512 to get to the beginning of the previous sector you now need to move -1024 This will be incredibly slow, so you would be better reading 64k at a time, but whatever block size you use, you will need to move backward blocksize x 2 I am correct Stefan? You may do better writing your own code and using the WinHex DLL Mike | ||
| Stefan Fleischmann (Admin) |
Correct, Mike. Turbo On will speed up the process a bit. The script should start with CloseAll to be sure to avoid undesired results of NextObj. | ||
| Stefan Fleischmann (Admin) |
As mentioned elsewhere already, the upcoming version of X-Ways Replica will support reverse cloning. | ||
| rjohnson |
How often does Replica update its log file? I am calculating just once, at the end of replicating? If so, would I be able to force it to write more often using my copying of selected ranges idea? In other words, does it automatically update the log at the end of replicating a range? Or using any other options? If not, I have another wish list idea: update the log file after a bad sector read (or as a command line parameter) or after evey X sectors. Should I clarify why? Thank you. | ||
| Stefan Kortmann (Admin2) |
The log file is updated after every read/write cycle. This includes also copying selected ranges. If Replica encounters a bad sector, the log file is updated immediately afterwards. | ||
| Stefan Kortmann (Admin2) |
X-Ways Replica 2.01 is available which flushes log entries to file immediately upon encounter of bad sectors. | ||
| rjohnson |
Just tested Replica 2.01 on an HD with some known bad sectors. Replica found and displayed on screen the bad sectors, I let Replica continue beyond them by a few thousand sectors, then killed power (to simulate lockups that are sometimes caused by bad sectors), reboot, viewed the log file, it just had the starting information? ----------------- BTW I do like the 'i' menu option for ATA info in 2.01. I see that it was availabale in 2.0 also but I had been using the noHPA version to avoid potential problems caused by hardware. In the Announcements forum there is mention of an '/a' switch now available (but not which version of Replica it is in). I have tried using it on 2.0, 2.0-noHPA and 2.01 and always get: ":" expected - "a" Only the noHPA version lists '/a' in the help screen (via '/h'), so I assume it is for that version only? In 2.0 to view HPA, however, it appears that HPA may be tested for by default when Replica 2.0 & 2.01 start? Because 'i' is a menu option, does Replica need to automatically check for HPA at start up(i.e. do they provide the same results)? If they are the same, I would opt for Replica to never perform an HPA on start up but rather always via the menu at the users descretion. Thus keeping HD access as basic and minimal as possible by default. | ||
| Stefan Kortmann (Admin2) |
I will simulate this scenario on our site again and make sure it will work properly. The /a option was implemented only in version 2.0 noHpa for an optional HPA check. In version 2.01 Replica always tests for HPAs on start-up since we have not had any negative feedback on hardware conflicts in association with the HPA check since. The "i" menu option triggers the same HPA check as on start-up. If it is of common interest to have the HPA check only as an option, we could change it in the next version. | ||
| rjohnson |
> The /a option was implemented only in version 2.0 noHpa The /a switch did not work in noHPA, which is OK because I was using noHPA to avoid HPA detection anyway. It was just FYI re: > and always get: > ":" expected - "a" But, as new versions of Replica come out, I imagine that it would not be likely to always expect mulit-variations for different needs (e.g. v2.01 noHPA), thus the suggestion to eliminate the HPA detect on start up, since it is also a quickly implementable menu option. > not had any negative feedback on hardware conflicts > If it is of common interest Other users of Replica -- please note the above. Do not to wait for a problem in the field to arrise and then ask for a solve when you can see this one coming. Imagine, you have the latest Replica ver X.xx with the newest features and it has worked great, but you finally get a hardware combo in the field that prevents vX.xx from starting, what will you do? Plan ahead, make your request now. ------ BTW, just today, Replica ver 2.01 used on a system with an add-in SATA/ATA combo only gave the HPA report on the onboard channels, which were all empty, but did not report on the SATA/ATA with two drives attached. I have not done a follow up on other similar systems, would this be of interest to you or is the HPA detect for mother board controllers only? This was not a problem since Replica continued, but it illustrates the potential problems that a multitude of unknown future hardware configurations may present (e.g. dual onboard controllers, future write-block hardware). I encourage the default access to be as minimal as possible and all other access to be either a menu option and/or command line option. | ||
| rjohnson |
I am surprised that I have not bothered you with this one before .... What happens if Replica should encounter bad sectors on the destination? Is the report file guaranteed to be exclusively reporting on the source only? Or is it reporting on all bad reads indicated by the controller(s) (assuming that a controller may perform reads in the course of writing) and possibly inter-mixing them in the report without declaring a drive? Yeah, yeah, I know that the destination should be pre-tested (pre-certified), but sometimes (rarely, hopefully) the destination can sour after being certified. Is Replica vigilant about this? Thank you for any clarification. | ||
| Stefan Kortmann (Admin2) |
The error message ": expected" came up with every unknown switch, because switches are supposed to have a ":" by default. The error "unknown parameter" would have occured if you had written e.g. "replica /a:" afterwards. This is fixed in version 2.02 now, unknown parameter characters throw an error right away. The flushing did not work for some reason when you rebooted the machine in process. This is fixed now in 2.02. Replica is able to report ATA information for drives which are connected to the primary and secondary host controllers on board. Other configurations are not handled. In case of write errors an error message will be shown on screen, no matter if you are logging or not, where you can decide to continue or exit. They are not logged at any rate. The HPA detection on start-up is handy for daily practise in some cases for what we know. If there are program hang-ups related to this auto-detection and hardware configuration, I encourage to let us know immediately, so we can work it out for the special case. | ||
| rjohnson |
> The HPA detection on start-up is handy for daily practise I have observed that the HPA is inconsistent in what it reports. I have spent quite a few hours testing and re-testing (confirming) different versions of Replica on different systems. On all systems tested, Replica 2.01 & 2.02 will report junk information regarding empty onboard EIDE connections. There is so much to say, I would rather provide a copy of the printouts (anyone know how to send 'Print Screen' button output to a file?). I will give a few non-detailed examples to try: 1. Start Replica 2.02, note the HPA report, then also do the 'i' option and compare. I have found that the results are most often different on the second read and then the same as the second read from then until Replica is restarted, then the pattern either repeats or, on at least one machine, the report is at its best (no data on empty connections and the correct info on a used connection). this happens on most machines tested here. usually the differnce is one of three things (depending on the system): a. a drive that is attached is not reported until the second read. b. the number of connections reported changes after the first read. c. The number of drives with HPA areas is zero on the second read when there may have been some reported during startup (those were usually the empty connections). On all the machines tested, I do not believe there was ever a drive in the Primary Master connection (I have not taken more time yet to test that), perhaps that makes a difference? Replica more often then not reports on empty connections with 'junk' information such as '-25.2GB) On one system, whenever Replica 2.01 or 2.02 was restarted a second time and the 'i' option was chosen, Replica consistently caused the system to repeatedly beep and slowly print an 'l' to the screen for every beep, forcing a system restart. Summary: On four systems tested, all had some degree of inaccurate information reported When Replica was initially started, then using the 'i' option the report would vary. Though each machine may have had differing results from other machines, each machines results could be consistently reproduced. | ||
| David Hansen (Dh) |
To print a "print screen capture" you could "print screen" then open MSWord or whatever you use and choose edit from the "file menu" then choose "paste" this should "paste" the "print screen capture" in the word document, then just print it. I have confirmed this,should work ok. | ||
| David Hansen (Dh) |
Reread Post, instead of print choose save file as to save it as a file to send ,,,sorry | ||
| Stefan Fleischmann (Admin) |
David: Thanks, but X-Ways Replica's ATA information screen is available under pure DOS only. | ||
| Anonymous |
Maybe this link can help to get the print screen to file under dos.... http://www.computing.net/dos/wwwboard/forum/14604.html | ||
| David Hansen (Dh) |
Thank you for being so nice about that:-) OK,I checked out the next post and found the link for Screen Thief not to work, ran a search found it and tried it out. It worked real nice maybe this will help you out. the link for the page is http://lists.gpick.com/pages/MS_DOS.htm the link for the download on the page is ftp://garbo.uwasa.fi/pc/gifutil/st201f.zip I also tried out to output as txt, worked fine. | ||
| rjohnson |
I forgot to mention that during testing of Replica this week, I found that Replica 2.01 was not working with image files as a source on two trys. Did not try 2.02 or other hardware yet. I am including the log here: --------------------------------------- X-Ways Replica 2.01 2004-8-9, 13:22:06 Source : c:\img\img.000 (image file, total size -1,442 MB) Destination : Hard disk 2 (28.6 GB) Absolute start sectors: 0 -> 0 -1,512,081,920 bytes will be copied. Bad sectors will be replaced with sectors of destination disk. 2004-8-9, 13:22:06 0 sectors were copied. 0 bad sectors were encountered that could not be read. -------------------------------------------------- | ||
| Stefan Kortmann (Admin2) |
Image sizes > 2 GB produced an overflow which has been fixed in the now available version 2.1 of Replica. | ||
| rjohnson |
I have been waiting to see if anyone else brings this up but not so far, so here goes... Replica 2 thruough the present does not run scripts via a batch file as does an earlier version (the NoHPA version). I have not tried basic command line entries in place of the batch file commands, but I would assume the same results. Sorry for the bother. Perhaps it is only on my hardware and thus no others have said anything? The batch file starts Replica properly and has the command line paramters following it such as: replica /f:c:\sectors /s:3 /d:2 /l:c:\log.txt then replia halts and complains that the first paramater is not correct (I cannot remember the exact wording). The same batch file works with the noHPA version (adjusting for the name of replica). | ||
| Stefan Kortmann (Admin2) |
This error came into play starting in version 2.02 when the internal parameter syntax check was changed. I have re-fixed it to work like before in version 2.11. | ||
| Ross Johnson Username: ross_winpro_net Registered: N/A |
I know it is a long time between occurrences but I have encountered another HD that will not work with any version of Replica that checks for HPA. The hard drive will work with versions of Replica that do not check for HPA, however those versions lack certain features that this case needs (i.e. limit on number of lines in a sector list). Would it be possible to obtain a noHPA version of Replica 2.36? Thank you, Ross@WinPro.net | ||
| Stefan Fleischmann Username: admin Registered: 1-2001 |
Yes, will add that to our To Do list and notify you and post again here when implemented. |