Your program is not recovering the images because the cs50 appliance or linux in this case uses the little-endian convention to store or read the data. I really don't know very much about this myself, but if you are interested in this topic you can start by reading in the wikipedia.
But long story short, when a variable has more than one byte, the bytes are ...
[EDIT: followup to comments]
The code never has a chance to get to a signature. There exists more than one block of garbage data at the front of the file, so the while loop needs to run a few times before it finds a signature. However, if the signature isn't detected immediately, the else clause inside the while loop will close the input file. When the ...
Can you give me an example of a filename that is supposed to contain a line feed?
sprintf(outfile, "%03i.jpg\n", foundPhoto);
As a side note, a programming tip. When you see to nearly identical blocks of code, maybe there's a way to rewrite it more efficiently, using only one block of code. Especially true when there are two blocks of code that ...
Seems to me that there were 50 files when I did this. They may have changed the data file again though. Having said that, look at the following:
while (fread(buffer, 1, 512, infile) == 512)
// Read the file into a buffer
fread(buffer, 1, 512, infile);
This is two consecutive fread() calls. It means that the data from the first read is ...
Program is not producing any jpgs because it is reading itself. Recall from the lecture the first element in argv is the program's name, so the problem is here.
FILE *card = fopen(argv,"r");
From the spec:
Thanks to FAT, you can trust that JPEGs’ signatures will be “block-aligned.” That is, you need only look for those signatures in a block’s ...
Are you sure that you are remaking the file after editing it, and that you're rebuilding the file that you're actually editing? Or that you're running the 2020 check50 slug?
I tested the code in check50 and it's fine.
I think the issue is with this line of code:
while (fread(block, sizeof(block), 1, input) == 1)
fread returns the number of items successfully read. So, if it successfully reads 1 block of data, it would return 512 and not 1. Since the condition isn't true, the while loop gets skipped and the program exits.
Edit: you are also returning 0 upon reading the ...
You fread two blocks, but fwrite one. Remove the first fread.
You don't seem to increment fileCount if it is 0. Which is a problem, as it will never leave its value of 0.
Please don't use & when dealing with conditionals, that's the bitwise AND. Use &&, the logical AND, instead. Will probably still work here, since == returns 0 or 1, even ...
You have multiple fread, each reading 512 bytes, but not every read sector seems to be written even after opening a file. This means you're skipping some sectors.
Instead of a do..while loop, use a regular while, and remove any fread in the body, keep only the one in the condition. This will take care of reading and checking for input file end at the same ...
The first step is to identify which line is triggering the seg fault.
When the code writes to the output file, has the file been opened yet?
If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance.
The program never finds a jpg signature because this test (buffer & 0xf) == 0xe0) is wrong. Suggest you review this answer by @Cliff B for an excellent explanation.
After you sort that out, there's other problems brewing with some of the fwrites. After you fread into buffer and find a signature, this fwrite(imageFile, 512, 1, img); will write out the ...
It means exactly what it says. If you find a signature pattern, the chances are high that this will mark the start of an image file. BUT, its also possible that there is stored data that will match a signature, completely by coincidence. A certain combination of a couple of consecutive pixels of the right colors could produce raw data that is also the same ...
Since counter is reset to 0 after every fread, it will never be 40. Perhaps filter out the noise by making the else condition something different, perhaps printf("."); to just "mark" a read. IMO you're making it too hard on your cognitive load to filter through 23,000+ lines of output.
One thing not accounted for in this design is the possibility of finding a "false jpg sig" in the middle of a 512-byte block. Recall from the spec:
Thanks to FAT, you can trust that JPEGs' signatures will be "block-aligned." That is, you need only look for those signatures in a block’s first four bytes.
Think "greedy". Since the sigs are "block-aligned", ...
It's amazing how often one small oversight can trash an entire program! Welcome to the wonderful world of "Oops, I missed something small!" We all get this, more often than we care to admit! ;-)
The good news is that your program logic works. In your program, the code checks for the signature with a for loop that counts the number of matching bytes and then ...
Are you sure this code is recovering all 50 jpgs? It seems to me like you're missing half the files and only recovering 25 pics, because you're calling fread here:
fread(buffer, sizeof(BYTE)*512 , 1, file);
And then here again, before writing it:
if (fread(buffer , sizeof(BYTE) * 512 , 1 , file) !=0)
Also, you're allocating only 3 chars for "title", ...
while(!feof(fp)) Review Week 4 > Shorts > File I/O (starting at 7:30) to remember why you shouldn't use !feof to control the while loop.
fread(&buffer,32,1,fp); 32? From the spec:
cameras only write to those cards in units of 512 B.
(buffer == 0xe0 ||buffer == 0xe1)) Make sure you are working from the current specification. It says:
I just finished the PSET myself but was browsing here because I was struggling with a segmentation error.
Anyway, noticed that our structure of the code is pretty much identical. I only noticed one difference at the end your code that I found interesting.
Just a friendly suggestion for optimization. You could lose some additional lines and duplicate code, ...