- Banned
- #61
conrad gaunt
Banned
- Joined
- May 31, 2007
- Messages
- 946
- Reaction score
- 0
- Points
- 0
Ronx, interesting. But don't you have to read every byte of a source file in order to generate a checksum before the copy? How does yours differ?
Michael
It doesn`t create a checksum. If you`re downloading a large file, using say bittorrent or p2p, checksums help to verifiy that the file you are copying is genuine. We already know our red footage is genuine, because we just filmed it onto our CF card. Its genuine even if our CF card has a disk error, since there isn`t another copy in existance to replace it with (unlike using bittorrent which will seek out an alternative source for the corrupt data). The software is simply written to make sure that what went on the CF is the same as what ends up on my backup drive, so all we have to do is read what is written to the destination disk and compare each byte with what was just read. The comparison is very simple and goes something like this:
if source_byte is not equal to destination_byte then theres an error (report it) else everythings ok (so read and copy next chunk to end of destination file)
This is perfectly adequate, since two bytes can`t be "identical AND different", at the same time (unless you use a drive system based on strange quantum physics, but that technology hasn`t been conceived yet)
You could of course create a checksum, if you wanted, to check your data COPY hasn`t become corrupted at a later stage, but if you`re using a fault tolerant RAID system it will detect and repair errors that occur later on in the files life span, automatically (so we won`t do its work for it).
So, it basically stops periodically (whilst copying) and reads the last chunk of data that was copied, and compares it to the data it just read (while its still in the memory buffer, to avoid having to read input data twice), and keeps doing this till the file is copied. Below is what I wrote in an earlier post on this thread (befoe I actually created the prototype to check I wasn`t talking rubbish, which I never ever do
NB, for any non-programmers reading, files can be opened in READ, WRITE and APPEND mode, explained below.
APPEND allows data to be added to the end of an existing file, like the one we`re creating during copying.
WRITE mode creates a new file (over writing any file that already exists, effectively deleting it during initialisation). We can then write to the file until the CLOSE command is executed (which it must be if we wish to change file modes). This mode is only used once by my software.
READ mode is self explanatory, allows reading any part of the file. I use a command called SEEK to move to any byte location in the file.
1) Buffer some data from file being copied
2) Write buffered data to new file (on hard disk)
3) Close the new file (on the destination disk), then immediately open in read mode
4) Read newly written data from new file (ie goto end of file minus the size of the read buffer), compare to data form original file (still in memory buffer)(display message if data differs)
5) If all goes well, close new file, then imediately open again (in file append mode) or exit (if data error)
6) Repeat process till file copied
done, new file is identical (assuming you don`t have faulty memory!). Using a good size buffer really speeds up disk copies too.