#6 crc32() does not compute a CRC32

[P Rouleau]

crc32() is only working with the first char of the buffer, ie the char c is always equal to buf[0].

[P Rouleau]

Sadly, the fix is not easy. The function itself can easily be fixed, but every existing images would been seen as corrupted.

To fix it, the image's version have to be increased, which means that code have to be added to handle the image based on its version. One solution can be to automatically enable ignore_crc for images identified as version "0001", since the crc is not right anyway.

I wonder if adding a crc to every blocks is really needed. From my understanding, the image is usually sent trough a compressor, then recorded on disk. Most corruptions will happen on the disk. When the image is restored, it have to be decompressed first. If the data is corrupted on the disk, the decompressor will be the one who will detects it and it will stops. If we use a remote storage, its still the decompressor who is dealing with the corruption.
Corruption caused by the network is not possible has long tcp/ip is used, which most tools use.

[P Rouleau]

I have a patch for this. I still have to do some tests before pushing it.

It turns out to be easy to handle by using ignore_crc. Its is mostly an if/else to add in the restore code.

[P Rouleau]

I have push the patch on github. However, I would like to have some feedback about the usefulness of a crc for each block. If the compressor is the first to detects a corruption, it may be better to not fix the crc computation and use the image version 0002 to remove the crc instead.

[Thomas]

Thank you for your effect. I know this bug and Matthew Booth give us a review and patches at
https://github.com/mdbooth/partclone/commits/review .

We agree to upgrade image version to fix this issue, we also want to add md5sum or other checksum to test block. Do you have any suggestion ?

BR, Thomas.

[P Rouleau]

I do not want to be bold, but I suggest to remove the crc from inside the image. The actual crc have never worked and it did not permit to protect the data. So it is like it was never there. I am working on another patch to remove it. I still have to implement the support for version 0001 images, but my first tests show a big gain in speed and image size (bigger that the amount of crc bytes removed).

If you prefer to keep the crc on each block, I have a patch to move the crc table initiation outside the loop. It give a 30% gain in speed.

I have some questions, what is the best way to communicate with you? Nothing complicated, mostly to determine where to focus my attention.

Regards,
P.Rouleau

[Thomas]

Thanks for your suggestion.
My idea is use new checkusm method in new image format, let user to choice
1. no checksum; fast but no check data
2. crc; easy check but not very sow
3. md5sum; make sure data correct, slowest
4. blabla...

for patches, yes, every patches is important for me to improve partclone better. Did you use github or ?

I have github repository, i will push to there if i update something..
https://github.com/Thomas-Tsai/partclone

BR, Thomas.

[P Rouleau]

I'm using github. If you want, I can help with the implementation of these
options. I need the "no crc" one. ;) I like Clonezilla and I want to
contribute back if possible.

However, since it requires a change in the image version, I am wondering if
you have a plan of some kind, what should features need to be added, in
what priority. Should we use the forum or the mailing to communicate?

On Tue, Jun 4, 2013 at 12:36 AM, Thomas thomas_tsai@users.sf.net wrote:

Thanks for your suggestion.
My idea is use new checkusm method in new image format, let user to choice
1. no checksum; fast but no check data
2. crc; easy check but not very sow
3. md5sum; make sure data correct, slowest
4. blabla...

for patches, yes, every patches is important for me to improve partclone
better. Did you use github or ?

I have github repository, i will push to there if i update something..
https://github.com/Thomas-Tsai/partclone

BR, Thomas.

• [bugs:#6] http://sourceforge.net/p/partclone/bugs/6/ crc32() does not
  compute a CRC32*

Status: open
Created: Sat Jun 01, 2013 03:33 AM UTC by P Rouleau
Last Updated: Mon Jun 03, 2013 11:08 AM UTC
Owner: nobody

crc32() is only working with the first char of the buffer, ie the char c
is always equal to buf[0].

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/partclone/bugs/6/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

--
Bjarne Stroustrup: “C makes it easy to shoot yourself in the foot; C++
makes it harder, but when you do it blows your whole leg off.”