Pset4 recover not passing check50, but I can see the recovered .jpg files

Question

I have run my program and it works! I get 16 .jpg files, all of which I can see when I open them. When I run check50, however it fails on jpg 000.jpg and 001.jpg through 014.jpg, but not 015.jpg?!

I get this result: https://sandbox.cs50.net/checks/b33f06a424c1459696623564c18c4566

The point at which it fails is at "TODO." and it shows "TODO" for the result. I don't understand this. Can anyone make sense of it? Does it have to do with adding the \0 like this poster: Recover creates the pictures, able to view them, but listed as jpg? in ls and check50 fails ?

I can't figure out why this is. I tried Valgrind and get 0 of 0 errors, BUT I do see the allocs and frees are not equal:

==3349== HEAP SUMMARY:
==3349== in use at exit: 352 bytes in 1 blocks
==3349== total heap usage: 17 allocs, 16 frees, 5,984 bytes allocated
==3349==
==3349== LEAK SUMMARY:
==3349== definitely lost: 0 bytes in 0 blocks
==3349== indirectly lost: 0 bytes in 0 blocks
==3349== possibly lost: 0 bytes in 0 blocks
==3349== still reachable: 352 bytes in 1 blocks
==3349== suppressed: 0 bytes in 0 blocks
==3349== Rerun with --leak-check=full to see details of leaked memory
==3349==
==3349== For counts of detected and suppressed errors, rerun with: -v
==3349== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

It doesn't make sense to me that this error would cause the check50 to fail, but maybe I am missing something. Any help on this would be much appreciated!

Thank you all!

Answer 1

Have you checked that the files are correct? Have you run a file compare against a solution set, like the files generated by the staff solution? Are you sure the headers are correct? While the files may be viewable, if there are errors in the recovery process, they may not be viewable, but would be enough to fail the test. Let us know what the result of your file compare is, particularly if the headers are correct, and we can go from there. – Cliff B Apr 14 at 0:27

Thank you for your help! I don't see a solution set to test against ("Lest it spoil your (forensic) fun, the staff’s solution to recover is not available.") Do you know of a way to find them? That would be a big help. Since I'm just writing the same file header as I read in the raw file, I assume they are correct. Also, 015.jpg passes and I didn't do anything different with the header there! – Patrick Harper Apr 14 at 14:40

Could you load one of the correct recovered files so I can do a file compare? – Patrick Harper Apr 14 at 15:15

ok, my mistake. I forgot that no solution was provided for this one. Because of that, it would be a violation of the honor code to post any of them. However, I do see a couple of big clues here. You can see all of the output files, so something is working. Also, you are failing on all but the last file. That suggests to me that you are mostly copying the files correctly, but something is going wrong at the end of the copy. Perhaps you are copying part of the next file to the end of the previous one? Since there's nothing left after the last file, it comes out ok. – Cliff B Apr 14 at 18:46

Check the code that closes each file and make sure you are not copying anything extra to the end of the file, and that you are copying the last block into the file before closing it. If this doesn't do the job, then it's time that we look at the code. – Cliff B Apr 14 at 18:48

Ah, you were exactly right, Cliff! Thank you. I had mis-ordered my code and was adding the next header to the end of the prior file as well. Thanks for the debugging help! – Patrick Harper Apr 27 at 19:33

Answered.