SIze of file

[munish.nr]

Hi All,

I want to know the size of file (txt,img or any other file). i knoe
only file name.
how i can acheive this.
does anybody is having idea about that.
plz help.

rgrds,
Munish Nayyar

 

[David Lee]

off_t fgetstat(const char * pathname)
{
struct stat * stbuf;

if (lstat(pathname, stbuf) == -1) {
fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno));
exit(EXIT_FAILURE);
}
return stbuf.st_size;
}

 

[David Resnick]

Hi All,

I want to know the size of file (txt,img or any other file). i knoe
only file name.
how i can acheive this.
does anybody is having idea about that.
plz help.

rgrds,
Munish Nayyar

Have a look at the FAQ:

http://www.eskimo.com/~scs/C-faq/q19.12.html

-David

 

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi All,

I want to know the size of file (txt,img or any other file). i knoe
only file name.
how i can acheive this.
does anybody is having idea about that.
plz help.

I can only think of two methods to determine file size that are consistant with
the C standard:

1) fopen() the file,
initialize an unsigned long (or longer) variable to 0
until fgetc() returns end of file, add 1 to the counter
fclose() the file,

or

2) fopen() the file
fseek() to the end of the file
ftell() the position of the end of the file
fclose() the file

Both of these methods have their drawbacks. Character counting may give
different results depending on whether the file was opened in binary or text
mode, and fseek()/ftell() may or may not work, depending on the implementation
("a binary stream need not meaningfully support fseek calls with a whence value
of SEEK_END" and ftell() return value is either the absolute position (when used
on a binary stream), or some "unspecified information" when used on a text stream).

Your choice.

- --
Lew Pitcher
IT Specialist, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFC+1XaagVFX4UWr64RAhyzAKCYNfPqV64rRBZ5p6SoxZoJxMvp5gCg7C80
colQvhV5MvyjLy/zhrNDSgA=
=CstA
-----END PGP SIGNATURE-----

 

[Chris Dollin]

Hi All,

I want to know the size of file (txt,img or any other file). i knoe
only file name.

Tell us why you want to know the file size.

 

[Default User]

off_t fgetstat(const char * pathname)
{
struct stat * stbuf;

if (lstat(pathname, stbuf) == -1) {
fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno));
exit(EXIT_FAILURE);
}
return stbuf.st_size;
}

Where are your definitions for off_t, stat, lstat?



Brian

 

[Keith Thompson]

off_t fgetstat(const char * pathname)
{
struct stat * stbuf;

if (lstat(pathname, stbuf) == -1) {
fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno));
exit(EXIT_FAILURE);
}
return stbuf.st_size;
}

First, please provide some context when you post a followup. Search
for "google broken reply link" in this newsgroup for many many copies
of the same explanation.

Second, the type "struct stat" and the lstat function are not defined
in standard C, and are therefore off-topic in this newsgroup.

 

[Flash Gordon]

David Lee wrote:

Please quote what you are replying to. Check CBFalconer's sig for
instructions.

off_t fgetstat(const char * pathname)
{
struct stat * stbuf;

if (lstat(pathname, stbuf) == -1) {
fprintf(stderr, "lstat %s failed: %s\n", pathname, strerror(errno));
exit(EXIT_FAILURE);
}
return stbuf.st_size;
}

Standard C does not have lstat or any of the related functions,
therefore your solution of off topic here since we only deal with
standard C. Had the OP indicated s/he was using unix you could have
redirected him to a unix group suggesting that solution since there is
no standard C solution to the OP's stated problem.

Please also read the FAQ, Google will give it to you if you ask it.

 

[Alexei A. Frounze]

(e-mail address removed) wrote: ....
Tell us why you want to know the file size.

Tell us what's wrong with such a desire? How about malloc'ing memory for the
entire file? How about comparing files (1st check being file size check)?
How about checking if there's enough space on some media to store it before
trying to store at all?

Alex

 

[Keith Thompson]

Tell us what's wrong with such a desire? How about malloc'ing memory for the
entire file? How about comparing files (1st check being file size check)?
How about checking if there's enough space on some media to store it before
trying to store at all?

The answer could be different for each of those three reasons.

If you want to malloc memory for the entire file, how are you reading
it? The size may be different depending on whether you read it in
text or binary mode. If you're comparing files, the meaning of "size"
might differ depending on the type of file. And if you want to store
it on some media, you probably don't know how much overhead is going
to be imposed by the file system.

On a Unix-like system, seeking to the end of the file and calling
ftell() will very likely give you a meaningful answer, but this isn't
a Unix newsgroup. On other systems, there may not even be a
meaningful answer.

 

[munish.nr]

Hi All,

Thank you very much for great response.
but my problem is still not solved.

let me reframe my problem!

i want to know the size of file ( the algo, solving this problem should
run on both windows and linux and also it should be tell us the file
size correctly whatever it be ( 1KB or 200MB)

i know only filename

so, is there any way to find the sizeof file in standard C ( so that
works on both platforms.)

also, the strcut lstat is vaild for unix, but is not standard c
compliant.

does anybody is having idea.?

Plz Help.

rgrds,
Munish Nayyar
emanshu "Innovative MInd"

 

[Alexei A. Frounze]

Hi All,

Thank you very much for great response.
but my problem is still not solved.

let me reframe my problem!

i want to know the size of file ( the algo, solving this problem should
run on both windows and linux and also it should be tell us the file
size correctly whatever it be ( 1KB or 200MB)

i know only filename

so, is there any way to find the sizeof file in standard C ( so that
works on both platforms.)

also, the strcut lstat is vaild for unix, but is not standard c
compliant.

does anybody is having idea.?

long fsize (const char* name)
{
long pos;
FILE* f=fopen(name,"rb");
if (!f) return -1;
if (!fseek(f,0,SEEK_END))
pos = ftell(f);
else
pos = -1;
fclose (f);
return pos;
}
That would be the most portable implementation.
Will work for file sizes up to ~2GB (due to long and FAT limitations).

Alex

 

[David Lee]

#include <sys/types.h>
#include <sys/stat.h>
It's UNIX/Linux specific.
______________________________________
In standard C, we can make use of fseek() & ftell().
And, don't forget fgetpos() & fsetpos().

The manual says:
On some non-UNIX systems an fpos_t object may be
a complex object and these routines may be the only
way to portably reposition a text stream.

 

[Walter Roberson]

long fsize (const char* name)
{
long pos;
FILE* f=fopen(name,"rb");
if (!f) return -1;
if (!fseek(f,0,SEEK_END))
pos = ftell(f);
else
pos = -1;
fclose (f);
return pos;
}

That would be the most portable implementation.

I do not have my reference manual here at home, but if I recall
correctly, SEEK_END has undefined behaviour for binary streams.

An offset of 0 in combination with SEEK_END is defined for text
streams, but the result of the ftell() not portably be the file size
in bytes -- the result of ftell() for text files is permitted to
be an opaque data structure.

 

[junky_fellow]

I do not have my reference manual here at home, but if I recall
correctly, SEEK_END has undefined behaviour for binary streams.

An offset of 0 in combination with SEEK_END is defined for text
streams, but the result of the ftell() not portably be the file size
in bytes -- the result of ftell() for text files is permitted to
be an opaque data structure.

You are right.
N869 Page 271:
"Setting the file position indicator to end-of-file, as with fseek
(file, 0, SEEK_END), has undefined behavior for a binary stream
(because of possible trailing null characters) or for any stream
with state-dependent encoding that does not assuredly end in the
initial shift state. "

 

[Chris Dollin]

Tell us what's wrong with such a desire? How about malloc'ing memory for
the entire file? How about comparing files (1st check being file size
check)? How about checking if there's enough space on some media to store
it before trying to store at all?

I wasn't asking you for your speculation; I was asking the OP for
their objective. What answer we give would depend on the objective.

 

[Chris Dollin]

Hi All,

Thank you very much for great response.
but my problem is still not solved.

let me reframe my problem!

i want to know the size of file ( the algo, solving this problem should
run on both windows and linux and also it should be tell us the file
size correctly whatever it be ( 1KB or 200MB)

*Why* do you want to know the size of the file?

[Note that "the size of a file" need not be an unambiguous term.]

 

[emanshu, Munish Nayyar]

Hi Chris,

I am developing one real time protocol.
and my requirement is my rate control calaculation algorithm requires
file size.

also, the protocol i am developing is to use UDP and Provide QoS and
reliability and Real Time characterstics in proposed protocol.

I hope this is more than enough information.

now can u help me.

rgrds,
Munish Nayyar
emanshu "Innovative MInd"
Zazu Networks,Inc.
(e-mail address removed)

 

[Richard Bos]

I'm not entirely sure.

You are right.
N869 Page 271:
"Setting the file position indicator to end-of-file, as with fseek
(file, 0, SEEK_END), has undefined behavior for a binary stream
(because of possible trailing null characters) or for any stream
with state-dependent encoding that does not assuredly end in the
initial shift state. "

That's a non-normative footnote, though. The actual text says:

# A binary stream need not meaningfully support fseek calls with a
# whence value of SEEK_END.

Note: meaningfully. IMO, the logical interpretation is that a binary
stream must support SEEK_END, in that fseek() is not allowed to crash
(and thus it's not truly undefined behaviour), but that the value
returned need not have any connection to reality.

Richard

 

[Chris Dollin]

Hi Chris,

I am developing one real time protocol.
and my requirement is my rate control calaculation algorithm requires
file size.

So, if it's real-time code, anything that reads through the file
in advance isn't acceptable, yes?

On the other hand, a reasonable *approximation* to the file size
would be OK, yes?

This code isn't intended to be ANSI-portable, because the real-time
features won't port cleanly, yes?

also, the protocol i am developing is to use UDP and Provide QoS and
reliability and Real Time characterstics in proposed protocol.

I hope this is more than enough information.

I'd say that given your requirements, use whatever non-portable system
calls for file size your platform supports: a clean ANSI-C solution
is neither available nor desirable.