Thread: Determine file size

I have a very dumb beginner question:

How to determine size in bytes of file in c?

Thank you

Yes, using only C standard functions.

Code:

int br;
        while(!feof(fp)) {
            fscanf(fp, "%d", &br);
            filesize+=sizeof(br);
    }

It is OK if all data in file is of type integer. But what happens if there are different data types in file?

First off, while(!feof(fp)) is almost never the right thing to do. You should instead check the return value of your read function, which will tell you whether you've hit EOF.

To get the file size (or more accurately, to find out how many bytes you can read, which is not necessarily the same thing), you would not want to use fscanf(); instead, something like:

Code:

size_t n = 0;
while(getc(fp) != EOF) n++;

But to really get the file size, you want a platform-specific function, as cpjust mentioned.

Someone may mention the trick of using fseek() to go to the end of the file and then ftell() to get its size, but as tends to be the case with C, there are problems with that approach: 1) fseek() with SEEK_END (ie, the end of the file) on a binary stream need not work, and 2) ftell() on a text stream might return a value that is meaningless to you.

C is fun like that.

Originally Posted by cas

Someone may mention the trick of using fseek() to go to the end of the file and then ftell() to get its size, but as tends to be the case with C, there are problems with that approach: 1) fseek() with SEEK_END (ie, the end of the file) on a binary stream need not work, and 2) ftell() on a text stream might return a value that is meaningless to you.

C is fun like that.

You hit me on the right spot. I was experimenting with the code below to find the file size but it always returns 21 (though the file size is 145kb)


[insert]

Code:

#include <stdio.h>

int main()
{
	FILE *fp;
	long file_size;
	int size;

	fp = fopen("C:\\Documents and Settings\\ROHAN\\Desktop\\DESKTOP\\filejava.txt", "rb");
	if(fp == NULL)
	{
		printf("\n Error opening the file");
		return 0;
	}

	size = file_length(fp);
	printf("\n Size of file is %d", size);

	close(fp);

	return 0;
}


int file_length(FILE *f)
{
	int pos;
	int end;

	pos = ftell (f);
	fseek (f, 0, SEEK_END);
	end = ftell (f);
	fseek (f, pos, SEEK_SET);

	return end;
}

But i couldn't understand why?????

Originally Posted by roaan

...
But i couldn't understand why?????

For starters you're opening a FILE stream but calling close() which takes a file descriptor as an argument.

Don't know about Windows but Unix doesn't make any distinction between binary and text files. So fseek() followed by ftell() will give you the correct size of the file. Alternatively you can call getc() to read a byte at a time until EOF. Both methods will work on any of the Unixes.

Originally Posted by itCbitC

For starters you're opening a FILE stream but calling close() which takes a file descriptor as an argument.

Don't know about Windows but Unix doesn't make any distinction between binary and text files. So fseek() followed by ftell() will give you the correct size of the file. Alternatively you can call getc() to read a byte at a time until EOF. Both methods will work on any of the Unixes.

Oh yes that was a typo and i was thinking why it was giving me an error .... now changed it to fclose()...

Also i am on a windows machine so fseek() and ftell() give some rubbish garbage as pointed out in the above post for the c99 standard

Well, reading all data using getc is a horrible solution, really. Even though the standard apparently doesn't describe a portable, other way, I would never use such a thing. Imagine a 2GB file where you need to know the filesize and then only a portion of the file. It would take several seconds to determine the filesize, while using unportable techniques it would be only a few clock cycles. Just write it for your OS and re-write it if you need to port it.

Anyway, does the same hold true for C++ files? As in, doing seekg and tellg on an std::ifstream being illegal?

It would take several seconds to determine the filesize

Plus flushing everything out of the disk cache, dramatically reduce the computer's responsiveness afterwards, at least for Linux.

No doubt getc() is a drag on largefiles. There are obvious tradeoffs between the portability and efficiency of a solution. IMO stat() or fseek() / ftell() are the preferred ways to get the filesize but on Windows they apparently won't work. getc() is portable but very inefficient. So there you have it - pros and cons of each solution and perhaps the o/p should pick the one that best suits the requirements.

Originally Posted by cpjust

Why won't stat() (a.k.a. _stat()) work on Windows?

Never coded in Windows so I couldn't say but the fact that stat() on Unix is _stat() on Windows is platform dependent.

Originally Posted by itCbitC

Never coded in Windows so I couldn't say but the fact that stat() on Unix is _stat() on Windows is platform dependent.

I feel happy for you! I've had the misfortune of having to code on VS about 3 times. Wow it's bad. All the basic string functions they don't like they add warnings about. strcat? No, use strncatuhegreg instead (I don't remember the exact name, only that it was a retarded extension intended for people who can't code).
And then.. _stat? Are you kidding me? Those naming conventions are nearly as bad as PHP.
What will we do to that name? Hmm let's add an underscore prefix. Or two. Let's add a random character to the end of it. Let's just scrap a function entirely and make our own.

It's disgusting.

I hope, for your sake, that you never will have to code on Windows. At least not on VS, I reckon other compilers like gcc do a pretty good job.
Don't even get me started on that dev-c++ crap. For fun, compile something and then open it with a disassembler. Don't be surprised to see one register being written to only to never be used before it's overwritten again. Oh, and the automatic indentation is the worst I've ever seen. Not to mention the many crashes I've experienced.

Again. Stick to non-Windows if you can.