"I apologize. I offer a complete and utter retraction. The imputation was totally without basis in fact, was in no way fair comment, and was motivated purely by malice, and I deeply regret any distress that my remarks may have caused you, or your family, and I hereby undertake not to repeat such a slander at any time in the future."
Just one more reason to not buy any preview-infested Blu-Ray discs and just use my $$ to stream videos from the internet.
Alan Turing's work continues to demonstrate "what a tremendous importance it has in the foundations" of computing technology in general, not just crypto.
Nowadays, IDE keeps a list of bad/remapped sectors and does all this in the background *as long as it's told to* -- if nobody ever reads offset 17543, nobody knows that is about to go bad (lets say ECC can correct for 1 in 96 bits, and right now there's an error in 1 of 108 bits), and over time, that will degrade to 1-in-96 at which time the data is lost. If SpinRite (or any other parity scrubber) reads the data while it's good, the drive electronics should notice the high error rate and refresh it. Some drives won't write the correct data back to the disk unless told to (it slows the drive down)...
I mostly agree with this. Sectors can degrade over time, so a "refresh" will essentially fix it. The problem is that drives don't necessarily do this (some drives have offline scans, but it's not guaranteed). As you've pointed out, a degrading sector can go unnoticed until someone actually requests to read that sector. And, perhaps this is where most people are frustrated with Spinrite's marketing. Just doing a read and then re-write to a sector isn't magic. The point is that when Spinrite encounters an error that it cannot read, it goes thru a series of steps to try and *enable* the HDD to read the sector. For example, it moves the actuator at varying distances from the target LBA to try and get it to seek settle at a slightly different location on the track. This is important because tracks are typically wider than the read head, so you can have different but acceptable actuator/head locations on the same track/sector.
My point about the ATA command is that Spinrite is only using standard commands; not undocumented commands or anything secret like that. However, what is "special" are the sequence of commands used to help the drive recover sectors that get a read error.
Ok, using what you just said, explain the "Dynastat Data Recovery" in Spinrite. To refresh your memory, that is where it claims to be working down to the bit level. You cannot address individual bits or even bytes on a drive, either with BIOS or direct ATA commands. And before you say something stupid about "averaging" or other mathematical BS, a modern drive can only return one of two things for a sector request. The correct data when the ecc matches, or an error.
I'm not sure what Spinrite is using, but there is a way to do this. It's not widely used, but there's a command called "Read Long", along with a complimentary "Write Long":
INT 13h AH=0Ah: Read Long Sectors From Drive (Reference: http://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D0Ah:_Read_Long_Sectors_From_Drive)
This returns data including bad data along with the ECC. This allows for error bits to be read along with the correction field. You can use this to essentially do offline error correction, but it will also give you the ability to get "parts of a sector".
Anyone see these guys on a port other than 22?
+1. Moving to a different service port dropped my failed login attempt logs down to nothing (at least, for now). Prior to that, my logs still weren't too big because I block IPs after #MAX_ATTEMPTS within a 24 hour window. However, the attempts were coming in at a rate of 10 minutes apart. Still, they got blocked. It's just that the hacking community seems to be well aware of trying to keep the number of attempts / unit time down to avoid detection.
Spinrite is lying about even using ATA commands
You seem to have it in for Spinrite, but it's not clear why. If you listen to Steve's podcast (Security Now), you'll know that he is very careful on how he describes the technical aspects of his products (including Spinrite). I'd be very surprised if you or anyone could point to any of GRC's literature on Spinrite that would prove he's "lying" about anything.
I'm not sure where Spinrite claims anything other than using Int13 commands. That's how it gets its minimalist compatibility with a DOS system using the system BIOS. For a SATA drive connected directly to the motherboard thru a standard SATA host adapter use regular ATA commands.
A USB connected SATA HDD simply gets help from the BIOS so that it can use Int13, converting to the USB commands, and then over the USB bridge, eventually going back to a standard ATA command (the only commands a SATA drive knows).
My point about the ATA command is that Spinrite is only using standard commands; not undocumented commands or anything secret like that. However, what is "special" are the sequence of commands used to help the drive recover sectors that get a read error.
Spinrite may do an OK job of exercising disks, but 90% of what it claims to do is BS.
This is a very uniformed opinion about Spinrite. Spinrite has a large population of testimonials that prove that "it works". It's main purpose is data recovery and data maintenance on magnetic-based rotational media.
Your example of a USB drive is just another way of saying "flash", for which Spinrite is not targeted to fix.
Indeed, there are no more "low level" commands like in the day of old HDD technology. However, Spinrite uses the standard ATA command set to do everything possible to get your data off your drive. It does this very well and you'll be hard pressed to find other programs that do it better that don't cost a lot, lot more money (think data recovery repair center).
It's also a terrible data recovery program, since it can only write recovered data back to the same disk
Spinrite doesn't target this case. Backing up is what you do *after* you use Spinrite to first correct the few sectors that are preventing your system from recognizing the disk in the first place.
You really need to review the product, what it's targeted to do, and the testimonials before you continue to bad mouth a product that has been shipping for as long as Spinrite has.
All right, all right, I apologize... I'm really really sorry... I apologize unreservedly... I offer a complete and utter retraction. The imputation was totally without basis in fact, was in no way fair comment, and was motivated purely by malice, and I deeply regret any distress that my remarks may have caused you, or your family, and I hereby undertake not to repeat such a slander at any time in the future.
I'm left handed and I'm accustomed to having to play some games that were made for right handers anyway. I mean, the location of the D-Pad on a NDS (as well as many other gaming controllers) is basically easier for a right hander to play. I still enjoy using / playing it.
I guess I've just adjusted to living in a (mostly) right-hander's world.
I've used bluetooth mice and keyboards at work and home. It's nice if the computer already has a bluetooth adapter as they don't require an extra port. In addition, the bluetooth has better range, so it's nice for a conference room where the computer is far from the keyboard & mouse.
However, for most applications, the negatives outweigh the positives.
Compared to the IR/RF counterparts, bluetooth devices are slow to respond. This is because of power management. The bluetooth devices consume more power, so they aggressively go into power-down modes to increase battery life. As a result, they take extra time to come out of the low-power modes and that's annoying, bordering unusable.
In addition, the fact that bluetooth requires an extra pairing process, when the device becomes unpaired it takes extra steps to restore it. Devices become unpaired when you push the connect buttons on the bottom of the device. This happens a lot when users think that the device isn't working (because it's slow to respond, see above).
These 2 issues result in a worse overall user experience.
Never test for an error condition you don't know how to handle. -- Steinbach