Has anybody used these ? They are written in c opposed to asm which would proberly make them portable, as far as i know spinrite is only written for x86 chips.
Previously geletine <adaviscg1@hotmail.com> wrote:> Has anybody used these ? They are written in c opposed to asm which> would proberly make them portable, as far as i know spinrite is only> written for x86 chips.
I use dd_tescue for all kinds of stuff. I have used it to recover data from media with defect sectors several times. It works insofar that it does get all the data in files or partitions that the drive is still willing to give. It also has the nice option to not write anything to the target if the source sector was not read successfully. That allows to combine the results from several reads.
Pretty versatile and powerful, but you need to understand what you are doing. A typical Unix utility in that regard.
AFAIK dd_rescue needs glibc. With that it is already pretty portable to many different platforms. Still, it should be easy to port to any other Unix-like OS and may be portable to the giant island of incompatibility (Windows) too.
Pretty versatile and powerful, but you need to understand what you are> doing. A typical Unix utility in that regard.
I am a unix user myself, so it should not be a problem>
AFAIK dd_rescue needs glibc. With that it is already pretty portable> to many different platforms. Still, it should be easy to port to any> other Unix-like OS and may be portable to the giant island of> incompatibility (Windows) too.
I should compile under MinGW or Cygwin in that case.
Folkert Rienstra 5 July 2006 02:20:24 [ permanent link ]
"Arno Wagner" <me@privacy.net> wrote in message news:4gvtdhF1pfe6aU1@individual.net> Previously geletine <adaviscg1@hotmail.com> wrote:> > Has anybody used these ? They are written in c opposed to asm which> > would proberly make them portable, as far as i know spinrite is only> > written for x86 chips.>
I use dd_tescue for all kinds of stuff. I have used it> to recover data from media with defect sectors several times.> It works insofar that it does get all the data in files> or partitions that the drive is still willing to give.> It also has the nice option to not write anything to the> target if the source sector was not read successfully.
That allows to combine the results from several reads.
Actually, that makes it rather more difficult.
Pretty versatile and powerful, but you need to understand what you are> doing. A typical Unix utility in that regard.>
AFAIK dd_rescue needs glibc. With that it is already pretty portable> to many different platforms. Still, it should be easy to port to any> other Unix-like OS and may be portable to the giant island of> incompatibility (Windows) too.>
Previously geletine <adaviscg1@hotmail.com> wrote:> Arno Wagner wrote:>>
Pretty versatile and powerful, but you need to understand what you are>> doing. A typical Unix utility in that regard.
I am a unix user myself, so it should not be a problem>>
AFAIK dd_rescue needs glibc. With that it is already pretty portable>> to many different platforms. Still, it should be easy to port to any>> other Unix-like OS and may be portable to the giant island of>> incompatibility (Windows) too.
I should compile under MinGW or Cygwin in that case.
I expect that should be possible with no or only miminal problems.
"'F'Nut" <see_reply-to@myweb.nl> wrote in message news:44ab1109$0$17949$892e7fe2@authen.yellow.readfreenews.net...> "Arno Wagner" <me@privacy.net> wrote in message > news:4gvtdhF1pfe6aU1@individual.net>> Previously geletine <adaviscg1@hotmail.com> wrote:>> > Has anybody used these ? They are written in c opposed to asm which>> > would proberly make them portable, as far as i know spinrite is only>> > written for x86 chips.>>
I use dd_tescue for all kinds of stuff. I have used it>> to recover data from media with defect sectors several times.>> It works insofar that it does get all the data in files>> or partitions that the drive is still willing to give.>> It also has the nice option to not write anything to the>> target if the source sector was not read successfully.>
That allows to combine the results from several reads.>
Actually, that makes it rather more difficult.>
Another redundant, and irrelevant comment, adding nothing to the thread and helping absolutely no one, by F'Nut. Thank you F'Nut.
Previously Joep <available@request.nl> wrote:> "'F'Nut" <see_reply-to@myweb.nl> wrote in message > news:44ab1109$0$17949$892e7fe2@authen.yellow.readfreenews.net...>> "Arno Wagner" <me@privacy.net> wrote in message >> news:4gvtdhF1pfe6aU1@individual.net>>> Previously geletine <adaviscg1@hotmail.com> wrote:>>> > Has anybody used these ? They are written in c opposed to asm which>>> > would proberly make them portable, as far as i know spinrite is only>>> > written for x86 chips.>>>
I use dd_tescue for all kinds of stuff. I have used it>>> to recover data from media with defect sectors several times.>>> It works insofar that it does get all the data in files>>> or partitions that the drive is still willing to give.>>> It also has the nice option to not write anything to the>>> target if the source sector was not read successfully.>>
That allows to combine the results from several reads.>>
Actually, that makes it rather more difficult.
Another redundant, and irrelevant comment, adding nothing to the> thread and helping absolutely no one, by F'Nut. Thank you F'Nut.
Actually it is not redundant, since it is completely wrong and misses the point.
"Arno Wagner" <me@privacy.net> wrote in message news:4h27mjF1p8g6mU2@individual.net> Previously Joepie <available@request.nl> wrote:> > "'F'Nut" see_reply-to@myweb.nl> wrote in message news:44ab1109$0$17949$892e7fe2@authen.yellow.readfreenews.net...> > > "Arno Wagner" me@privacy.net> wrote in message news:4gvtdhF1pfe6aU1@individual.net> > > > Previously geletine <adaviscg1@hotmail.com> wrote:> > > > > Has anybody used these ? They are written in c opposed to asm which> > > > > would proberly make them portable, as far as i know spinrite is only> > > > > written for x86 chips.> > > >
I use dd_tescue for all kinds of stuff. I have used it> > > > to recover data from media with defect sectors several times.> > > > It works insofar that it does get all the data in files> > > > or partitions that the drive is still willing to give.> > >
It also has the nice option to not write anything to the> > > > target if the source sector was not read successfully.> > > > That allows to combine the results from several reads.> > >
Actually, that makes it rather more difficult.>
Another redundant, and irrelevant comment, adding nothing to the> > thread and helping absolutely no one, by F'Nut. Thank you F'Nut.
Actually it is not redundant,
At least you got that right.
since it is completely wrong
Nope, it's rather obvious.
You can only replace wrong parts with good parts if you know that the individual parts are in the right place (in the right position) *in the file* AND which one of the parts is obviously wrong, which obviously you won't know if you leave out 'bad' parts. And obviously it's completely silly to COMPARE different files when you already know that all of them con- tain good data but are of different content and length. You may be able to decide which parts are more complete than other parts in the seperate files and cross-update them accordingly but you will never know which one is complete because you won't know what's missing.
With fake but easily recognizable 'bad' data that will not be a problem and makes cross-updating the individual files a breeze.
Zvi Netiv has a tool to cross-replace sectors between files but it is completely useless with files that have missing parts (actual or fake).
Previously Arbuckle, J.Q. <jon@garfieldandfriends.cartoon> wrote:> "Arno Wagner" <me@privacy.net> wrote in message news:4h27mjF1p8g6mU2@individual.net>> Previously Joepie <available@request.nl> wrote:>> > "'F'Nut" see_reply-to@myweb.nl> wrote in message news:44ab1109$0$17949$892e7fe2@authen.yellow.readfreenews.net...>> > > "Arno Wagner" me@privacy.net> wrote in message news:4gvtdhF1pfe6aU1@individual.net>> > > > Previously geletine <adaviscg1@hotmail.com> wrote:>> > > > > Has anybody used these ? They are written in c opposed to asm which>> > > > > would proberly make them portable, as far as i know spinrite is only>> > > > > written for x86 chips.>> > > >
I use dd_tescue for all kinds of stuff. I have used it>> > > > to recover data from media with defect sectors several times.>> > > > It works insofar that it does get all the data in files>> > > > or partitions that the drive is still willing to give.>> > >
It also has the nice option to not write anything to the>> > > > target if the source sector was not read successfully.>> > > > That allows to combine the results from several reads.>> > >
Actually, that makes it rather more difficult.>>
Another redundant, and irrelevant comment, adding nothing to the>> > thread and helping absolutely no one, by F'Nut. Thank you F'Nut.>
Actually it is not redundant,
At least you got that right.
since it is completely wrong
Nope, it's rather obvious.
You can only replace wrong parts with good parts if you know that> the individual parts are in the right place (in the right position)> *in the file* AND which one of the parts is obviously wrong, which> obviously you won't know if you leave out 'bad' parts. And obviously> it's completely silly to COMPARE different files when you already> know that all of them con- tain good data but are of different> content and length. You may be able to decide which parts are more> complete than other parts in the seperate files and cross-update> them accordingly but you will never know which one is complete> because you won't know what's missing.
As I said, you miss the point. The offsets for defective input sectors will be there in the target file, but no data will be in there. On reads that results in zeros. Alternatively you can have dd_rescue write "hard" zeros in the first copy, but that does nothing except to allocate more disk space. Obviously you have never heard that you can leave parts of a file unwritten. Or you have no idea how data in a file is addressed. Hint: Look up "sparse file" some time.
With fake but easily recognizable 'bad' data that will not be a problem> and makes cross-updating the individual files a breeze.
Wrong. With bad data is not written to the target, you can just copy the source several times to the same target, retaining all good data already written. If something "obviously bad" is written, that may erase good data written in previous copy passes.
"Arno Wagner" <me@privacy.net> wrote in message news:4h2rttF1pgdmbU1@individual.net> Previously Arbuckle, J.Q. <jon@garfieldandfriends.cartoon> wrote:> > "Arno Wagner" <me@privacy.net> wrote in message news:4h27mjF1p8g6mU2@individual.net> > > Previously Joepie <available@request.nl> wrote:> > > > "'F'Nut" see_reply-to@myweb.nl> wrote in message news:44ab1109$0$17949$892e7fe2@authen.yellow.readfreenews.net...> > > > > "Arno Wagner" me@privacy.net> wrote in message news:4gvtdhF1pfe6aU1@individual.net> > > > > > Previously geletine <adaviscg1@hotmail.com> wrote:> > > > > > > Has anybody used these ? They are written in c opposed to asm which> > > > > > > would proberly make them portable, as far as i know spinrite is only> > > > > > > written for x86 chips.> > > > > >
I use dd_tescue for all kinds of stuff. I have used it> > > > > > to recover data from media with defect sectors several times.> > > > > > It works insofar that it does get all the data in files> > > > > > or partitions that the drive is still willing to give.> > > > >
It also has the nice option to not write anything to the> > > > > > target if the source sector was not read successfully.> > > > > > That allows to combine the results from several reads.> > > > >
Actually, that makes it rather more difficult.> > >
Another redundant, and irrelevant comment, adding nothing to the> > > > thread and helping absolutely no one, by F'Nut. Thank you F'Nut.> >
Actually it is not redundant,>
At least you got that right.>
since it is completely wrong>
Nope, it's rather obvious.>
You can only replace wrong parts with good parts if you know that> > the individual parts are in the right place (in the right position)> > *in the file* AND which one of the parts is obviously wrong, which> > obviously you won't know if you leave out 'bad' parts. And obviously> > it's completely silly to COMPARE different files when you already> > know that all of them contain good data but are of different> > content and length. You may be able to decide which parts are more> > complete than other parts in the seperate files and cross-update> > them accordingly but you will never know which one is complete> > because you won't know what's missing.
As I said, you miss the point.
And gladly so, child. I would consider myself seriously under the weather if I ever found myself understanding your clueless rantings.
The offsets for defective input sectors will be there in the target file, but > no data will be in there. > On reads that results in zeros.
Alternatively you can have dd_rescue write "hard" zeros in the first copy, > but that does nothing except to allocate more disk space. > Obviously you have never heard that you can leave parts of a file unwritten. > Or you have no idea how data in a file is addressed.
Hint: Look up "sparse file" some time.
Then you should have mentioned that in your previous explanation, child. That's not obviously clear to any non-unix zealot. It also presupposes a system that supports that type of file. I'll bet Zvi Netiv's utility (from the part that you cleverly snipped) has never heard of it.
With fake but easily recognizable 'bad' data that will not be a > > problem and makes cross-updating the individual files a breeze.
Wrong.
Right with the methodology that works with user intervention, child. Where you replace bad parts in one file with good parts from another.
With bad data is not written to the target, you can just copy the source > several times to the same target, retaining all good data already written.
And still have holes in them that read as zeroes without knowing whether they are 'holes' or actual data of zeroes on a file system (or application) that doesn't understand sparse files.
If something "obviously bad" is written, that may> erase good data written in previous copy passes.
Sure, in your methodology that you failed to explain, child. Not in his.
In that methodology the failing data is easily recognizable provided the false data inserted was made easily recognizable.
In your example the false data are zeroes (whether on-disk or not) that may either represent a 'hole' or be (f)actual data of zeroes.
Previously Oscar Jones <hey@itsmenothim.com> wrote:> "Arno Wagner" <me@privacy.net> wrote in message news:4h2rttF1pgdmbU1@individual.net>> Previously Arbuckle, J.Q. <jon@garfieldandfriends.cartoon> wrote:>> > "Arno Wagner" <me@privacy.net> wrote in message news:4h27mjF1p8g6mU2@individual.net>> > > Previously Joepie <available@request.nl> wrote:>> > > > "'F'Nut" see_reply-to@myweb.nl> wrote in message news:44ab1109$0$17949$892e7fe2@authen.yellow.readfreenews.net...>> > > > > "Arno Wagner" me@privacy.net> wrote in message news:4gvtdhF1pfe6aU1@individual.net>> > > > > > Previously geletine <adaviscg1@hotmail.com> wrote:>> > > > > > > Has anybody used these ? They are written in c opposed to asm which>> > > > > > > would proberly make them portable, as far as i know spinrite is only>> > > > > > > written for x86 chips.>> > > > > >
I use dd_tescue for all kinds of stuff. I have used it>> > > > > > to recover data from media with defect sectors several times.>> > > > > > It works insofar that it does get all the data in files>> > > > > > or partitions that the drive is still willing to give.>> > > > >
It also has the nice option to not write anything to the>> > > > > > target if the source sector was not read successfully.>> > > > > > That allows to combine the results from several reads.>> > > > >
Actually, that makes it rather more difficult.>> > >
Another redundant, and irrelevant comment, adding nothing to the>> > > > thread and helping absolutely no one, by F'Nut. Thank you F'Nut.>> >
Actually it is not redundant,>>
At least you got that right.>>
since it is completely wrong>>
Nope, it's rather obvious.>>
You can only replace wrong parts with good parts if you know that>> > the individual parts are in the right place (in the right position)>> > *in the file* AND which one of the parts is obviously wrong, which>> > obviously you won't know if you leave out 'bad' parts. And obviously>> > it's completely silly to COMPARE different files when you already>> > know that all of them contain good data but are of different>> > content and length. You may be able to decide which parts are more>> > complete than other parts in the seperate files and cross-update>> > them accordingly but you will never know which one is complete>> > because you won't know what's missing.
As I said, you miss the point.
And gladly so, child.
Run out of arguments? Seems to be the case. Well, talking down to me is a poor and rather transparent substiute.
Here are my thoughts. If you want to get the data off the drive, never do anything to alter it. That is what SpinRite does. So, don't use it. Instead, get a good clone and try to avoid the damaged areas until you get as many of the good areas first...thus why ddrescue and dd_rescue are handy. I'm playing with the two programs now and noticed that with two good sata drives, I am getting a much faster throughput with dd_rescue (~50,000 kB/s vs ~ 110,000 kB/s)
I haven't tested them heavily on drives with media damage, as I have professional data recovery tools that are better for the job. However, if I didn't have my professional toolkit, I'd definitely have these running every day. In fact, the reason I'm playing with them right now is because I'm setting up a bootable USB key with FC11 and some useful tools for road.
Again, SpinRite is not a drive duplication tool. It is a program that remaps sectors, which is what the drive will do automatically, anyway. So, it really doesn't fit into this comparison. Instead it would be under SpinRite vs chkdsk vs ScanDisk vs Norton Disk Doctor.
Here are my thoughts. If you want to get the data off the drive, never do anything to alter it. That is what SpinRite does. So, don't use it. Instead, get a good clone and try to avoid the damaged areas until you get as many of the good areas first...thus why ddrescue and dd_rescue are handy. I'm playing with the two programs now and noticed that with two good sata drives, I am getting a much faster throughput with dd_rescue (~50,000 kB/s vs ~ 110,000 kB/s)
I haven't tested them heavily on drives with media damage, as I have professional data recovery tools that are better for the job. However, if I didn't have my professional toolkit, I'd definitely have these running every day. In fact, the reason I'm playing with them right now is because I'm setting up a bootable USB key with FC11 and some useful tools for road.
Again, SpinRite is not a drive duplication tool. It is a program that remaps sectors, which is what the drive will do automatically, anyway. So, it really doesn't fit into this comparison. Instead it would be under SpinRite vs chkdsk vs ScanDisk vs Norton Disk Doctor.
Since I have used both ddrescue / dd_rescue (which one you get primarily depends on the distro of Linux you're using), I will toss in my two kopeks.
1. I have *never* used SpinRite - so I won't speak to it. 2. I have had occasion to use "ddrescue" (pick your version) to resurrect a failed linear array on a Western Digital My Book World II (500 gigs per drive) arranged as a Linux RAID-0 software array.
ddrescue allowed me to recover virtually *ALL* of the "lost" data, and recover something like 30+ years of irreplacable archives. (I now have that on a 4T array set up as a 2T RAID-10.)
Yes. You *DO* have to really know what you're doing when you mess with disks at the "dd / dd_rescue" level - you can totally pooch yourself so easily it's not even funny. However if you're careful - and (as Data Recovery said), you *NEVER* touch the original disks (except to clone them to files, etc., with dd_rescue) - you should be headed in the right direction. (assuming the data's recoverable in the first place. . .)
Another use for dd_rescue: Assume you have some kind of physical media - a partition on a hard drive, on CD or DVD, etc. - where you may not know *exactly* how large the data is. Most disk tools get you close, and yes, you can calculate *exactly* how big, but with dd_rescue you don't have to.
You can simply dd_rescue the media to a file (say a CD/DVD to an ISO) - and it will read the data in large chunks until it gets to the end of the partition / media / etc. - then it stops, takes smaller and smaller bites (bytes? ) until it gets to the "EOF" (or end of partition), and then gracefully stops. You get everything you need without having to jump through hoops with calculations that (usually!) I would get wrong.
You can use dd for that too - but you need to know exactly how big because dd is not so forgiving - or adaptable - as dd_rescue.
What say ye?
Jim
p.s. No, I don't have the "professional data recovery tools" (drool! drool!)
If you would like to report an abuse of our service, such as a spam message, please . Если Вы хотите пожаловаться на содержимое этой страницы, пожалуйста .
