Printable View
Hi all,
I need to read the CRC value of the desired sector on hard disk. I DON'T need just to detect was there any mistake reading that sector, I just need to read the CRC value of the selected sector without reading the entire sector and calculating the CRC value by myself, ok?
Thank you all who help me with this, a lot!
burek.
The best I can do are these search results. Hope they help out.
thank you for your effort, but unfortunately those results all show how to calculate the crc value, and I need just to read the value that's written on the disk already.
;)
Not something there's heaps of help with by the look of it, but I think you'd be needing to use something like the Int13 service Read Long Sector:
http://www.htl-steyr.ac.at/~morg/pci...s/inte70og.htm
"reads regular data sectors (128-1024 bytes) with an additional
4 byte ECC code included"
so for standard 512 byte sector, bytes 513-516 in the buffer should be your CRC bytes, as that's where you'd expect CRC in the header. It's a bit confusing that they call it ECC, as that's different...
Plus this particular reference is only valid for CHS without translation, and it's too late here for me to be looking any more, but it might point you in the right direction I hope!
You're going to need a disk editor program to read the CRC value. WinHex is a good one, and I'm fairly sure it can do it. You can download a free trail anyway:
http://www.sf-soft.de/winhex/index-m.html
We're a little hampered by not knowing whether burek needs a one-off solution to just physically read the information off the screen, or a programming method. If burek is the questioner I see on another site asking the same thing, then a programming method is needed, and he or she is already aware of Int13 routines.
Further to my post above, I realised this morning I don't know if Read Long Sector works with modern NoID drives with sector ID data in NVRAM, but I think it would have to or current drives would break old applications. It's also been so long since I mucked around with hardware that I don't know how to do LBA access through BIOS services.
You're right, I apologize if I was confusing, but, I need the part of the code in ASM or c/c++ or so, that reads that crc value off the disk. The problem with those int13 routines is that it reads complete sector of data plus the additional data (Read Long Sectors, which reads the ECC also with the data). But I don't need to read the data from the sector, but only that little 2byte crc value. Nothing more..Quote:
Originally Posted by Platypus
Or if you have some links to the sites which explain the hard disk structure, so I'll try to hack it myself :)
Thank you all for your efforts.
burek ;)
I'm probably telling you what you already know, but HDDs are block devices, so at drive/interface level, a sector is the smallest amount of data that can be accessed, I don't think there is any practical way to do partial sector addressing. (In fact, with modern cached drives, for any read, an entire track is transferred into the drive's buffer, and all data read from buffer memory until an unbuffered location is requested.)
Is there too much overhead involved in extracting the CRC bytes from the return buffer & just discarding the remainder? Sometimes things just have to be done that way... :)
well I guess it will be that way :)
it's just.. I need to write some code that makes HASH code of some files..
So.. I recalled the fact that those crc codes of each sectors are already there on the hdd, and I just need to read them, and put together and my hash string is done.
Anyway, is there any crc for the block of data :)))
I don't know.. I think I'll give up this project.. But I'm so close to the solution, and every step that takes me a little bit closer, lasts longer and longer..
Anyway, I really appriciate your help ;)
Got you now...
Sometimes it's intensely frustrating that the information you need exists somewhere, but it's actually easier or faster to get it some other way.
For that application, the big problem with Int13 services would be how slow they are, it would be much faster to calculate the hash for the file than to extract the CRC for each sector the file is stored in. :(
No way Hose.. :)
Don't tell me that..
Just lie to me, but don't tell me that :(
:)
I just can't believe.. I can feel the solution is there.. but.. I don't know..
I think I should get some sleep, maybe the solution will pop up by itself..
However, thanx for help, really.
I owe you one :)
That's true, sometimes you wake up knowing just what to do.Quote:
Originally Posted by burek
Good luck :)
You may be able to get some answers to this one on our sister site here:
CodeGuru
In the very old days, sectors/clusters/tracks were physically written as SDLC "frames", ie, <StartOfData>data<CRC><EndOfData>. The SDLC chips had a
hardware accumulator such that the entire frame's CRC should add up to some
constant value (I think - this is from the '70s!). When clustering came along the cluster became the smallest physical unit of data that could be read, and I think CRC's became a CRC on the cluster, with no CRC on the sector. Now-adays
I suspect there's only one long CRC on the track. Either way, if the CRC is
still present at the sector level, you have to physically read the sector to get the CRC from the end of it... :)
Thank you :)