SIze of file

[Richard Bos]

[ Learn to use Google, or get a real newsreader. Quote context! ]

#include <sys/types.h>
#include <sys/stat.h>
It's UNIX/Linux specific.

Quite; and therefore off-topic here.

In standard C, we can make use of fseek() & ftell().

But not reliably to find the size of a file, which is what the subject
line tells me you are after.

The manual says:

_Which_ manual?

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.

Quite. Not a reliable way to get a file size, then.

Richard

 

[ahmed.mubin]

go through stat/lstat/fstat function

 

[Robert Gamble]

go through stat/lstat/fstat function

Huh? I have no idea what you are talking about since you quoted
absolutely no context. Whatever you were trying to reply to though,
your response is off-topic here.

Robert Gamble

 

[emanshu, Munish Nayyar]

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

But calculation of size of file and then calculating the rate control
both are not an real time issue.

real time here is file transfer. but i my problem is before that.

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?


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.

this solution might be acceptable, but for that i need to know about
the System calls for different OS.
i am just looking for alternative solution

rgrds,
Munish Nayyar

 

[Alexei A. Frounze]

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.

I treated what you wrote as if it was written as "there's no reason to know
the file size at all". Just that.

Alex

 

[Alexei A. Frounze]

Walter Roberson wrote: ....

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. "

Guys, I believe the standard can contain that kind of stuff (if it's in
there I'll find it if I want to), but however meaningless fseek (file, 0,
SEEK_END) by the standard is, there are some 6 different compilers of what I
know on 4 different OS/CPU platforms (dos, windows, linux, and something
else that I don't know how to call it, for there's no really an OS) and
everywhere I would get the right binary file size using fseek() to end of
file and then ftell()...

Alex

 

[Walter Roberson]

Guys, I believe the standard can contain that kind of stuff (if it's in
there I'll find it if I want to), but however meaningless fseek (file, 0,
SEEK_END) by the standard is, there are some 6 different compilers of what I
know on 4 different OS/CPU platforms (dos, windows, linux, and something
else that I don't know how to call it, for there's no really an OS) and
everywhere I would get the right binary file size using fseek() to end of
file and then ftell()...

Linux has support for a fair number of different filesystem types.
Did you try them all? How big is the index on that DVD? What happens
when you NFS over to an OpenVMS system? What size does your code
report /dev/zero to be?

 

[Keith Thompson]

I treated what you wrote as if it was written as "there's no reason to know
the file size at all". Just that.

Then you misunderstood. When he wrote "Tell us why you want to know
the file size", he probably meant "Tell us why you want to know the
file size.".

 

[Keith Thompson]

Guys, I believe the standard can contain that kind of stuff (if it's in
there I'll find it if I want to), but however meaningless fseek (file, 0,
SEEK_END) by the standard is, there are some 6 different compilers of what I
know on 4 different OS/CPU platforms (dos, windows, linux, and something
else that I don't know how to call it, for there's no really an OS) and
everywhere I would get the right binary file size using fseek() to end of
file and then ftell()...

Almost all the people I've met speak English. This doesn't lead me to
assume that everyone does. (Noting your ".ru" address and fluent
English, this is not aimed at you, it's just an example of an invalid
inference.)

When you view them from the perspective of all operating systems,
Windows and Linux are really very similar to each other. Certain
mainframe operating systems can do some very odd things.

I suspect that on all systems where feek() and ftell() give you the
correct size, there's a system-specific method to get the size of a
file directly. It's probably safer to use the system-specific
method(s), using #ifdefs to cover as many systems as you know about,
than to use the indirect and not quite portable fseek()/ftell()
method. If your program uses the stat() function and looks at the
st_size member of the result, you can be sure it will fail to compile
if you try to port it to a system that doesn't support stat(). If you
use feek() and ftell(), it may just quietly give you incorrect results
(as well as being less efficient on systems where it works).

Not all code has to be portable, and there is such a a thing as good
non-portable code vs. bad non-portable code.

 

[Chris Dollin]

I treated what you wrote as if it was written as "there's no reason to
know the file size at all". Just that.

You read more into my request than I wrote into it, in that case,
as well as crediting me with precious little in the way of imagination.

 

[Simon Biber]

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,

Hmm, let's see how that looks in C:

file = fopen(the file);
do {
unsigned long variable = 0;
} until (fgetc(file) == EOF);
counter++;
fclose(file);

Doesn't look very promising. Perhaps you missed some punctuation after
the zero?

 

[Lew Pitcher]

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


#include <stdio.h>


{
FILE *fp;
unsigned long count;

if ((fp = fopen("the file","r")) != NULL) /* fopen() the file */
{
count = 0; /* initialize count to 0 */
while (fgetc(fp) != EOF) ++count; /* until fgetc returns EOF, */
/* add 1 to the counter */
fclose(fp); /* fclose() the file */
}
}

Hmm, let's see how that looks in C:

file = fopen(the file);
do {
unsigned long variable = 0;
} until (fgetc(file) == EOF);
counter++;
fclose(file);

Doesn't look very promising. Perhaps you missed some punctuation after
the zero?

- --
Lew Pitcher

Master Codewright & JOAT-in-training | GPG public key available on request
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFDATBHagVFX4UWr64RAiMbAJwIvzeLCG9TIzhbfLXnHzMMe2cOUgCeOxo6
lk0pGN1IBXNA0S35eIcLGp8=
=d4q5
-----END PGP SIGNATURE-----

 

[Walter Roberson]

#include <stdio.h>

{

Hmmm, no main() .

FILE *fp;
unsigned long count;

Is a file size certain to fit within an unsigned long?
Answer: NO.

For example, SGI IRIX programs compiled in either
32 bit mode have 32 bit unsigned long, but the SGI XFS filesystem
supports individual files up to about 10 terabytes.

if ((fp = fopen("the file","r")) != NULL) /* fopen() the file */

And if the file isn't readable? The original poster asked how to
portably the file size, but only much much later implied that the
file might be readable.

{
count = 0; /* initialize count to 0 */
while (fgetc(fp) != EOF) ++count; /* until fgetc returns EOF, */
/* add 1 to the counter */

If I recall correctly, on systems that differentiate between
binary and text streams, opening with "r" opens as a text stream.
The number of chars read from a text file could be more or
less than the binary file size. On the other hand, Similarily,
if the file was written as text and is being read as binary, the
"size" isn't going to match either.

Now that I think of it, I don't recall that the standard promises
that a file written as text has any consistant meaning when read
as binary. For example, some systems automatically compress older
text files, and transparently uncompress them when the file is
read back as text -- but because the compressed file must be
manipuable in compressed format, reading the file in binary might
give you the compressed form. In such a system, reading a text file
in binary might give you different answers at different times.

The C standard doesn't care: it's promises are framed in terms
of what is read back in text mode after being written in text mode,
and in terms of what is read back in binary mode after being
written in binary mode.

fclose(fp); /* fclose() the file */
}

What value does count have here if the file was unreadable?

}

Since count was local to this block, the value of count has
disappeared by here, but you have not returned any value
nor assigned into any result variable that has a lnnger
lifetime. The optimizer thus might decide to throw away
the 'count' variable. Indeed, the only thing stopping the
compiler from optimizing away *everything* is the fact
that "the file" might be a named pipe and so there might
be side effects from having done the read (that and the
fact that in Unix the act of doing the read changes the
"last accessed" time.

 

[Richard Bos]

Hmmm, no main() .


Is a file size certain to fit within an unsigned long?
Answer: NO.

No, but it's the largest size integer you can get under C89.

And if the file isn't readable? The original poster asked how to
portably the file size, but only much much later implied that the
file might be readable.

If it isn't, what do you want the file size for in the first place?

Richard

 

[Walter Roberson]

(e-mail address removed)-cnrc.gc.ca (Walter Roberson) wrote:

If it isn't, what do you want the file size for in the first place?

Back when 18 Gb was a big disk, I used to have batch jobs that
scanned looking for old big files. I didn't need to look inside
the files, only to find out how big (and how old) they were;
the top abusers would then be sent email asking them to please
clean up.

 

[Richard Bos]

Back when 18 Gb was a big disk,

And when you tell youngsters these days that, they won't believe you?
Must be all of what, five years ago?

I used to have batch jobs that
scanned looking for old big files. I didn't need to look inside
the files, only to find out how big (and how old) they were;
the top abusers would then be sent email asking them to please
clean up.

In that case, you specifically do _not_ want to know the file size as C
sees it, but the amount of space it takes on the disk - including slack,
et cetera. And if that's what you want, there really is no C answer,
since that number depends not only on OS, but even on the file system,
and possibly on the size of the disk itself.

BTW, that would've been a prime candidate for a shell script rather than
a C program. Even, I think, under M$ OSes.

Richard