Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13122 > unrolled thread

how can i find the size of a binary file

Back to article view | Back to comp.lang.c

Contents

  how can i find the size of a binary file mark <nospam@nospam.com> - 2011-11-11 21:37 +0000
    Re: how can i find the size of a binary file John Gordon <gordon@panix.com> - 2011-11-11 21:48 +0000
      Re: how can i find the size of a binary file mark <nospam@nospam.com> - 2011-11-11 21:53 +0000
        Re: how can i find the size of a binary file jacob navia <jacob@spamsink.net> - 2011-11-11 23:00 +0100
        Re: how can i find the size of a binary file James Kuyper <jameskuyper@verizon.net> - 2011-11-11 17:20 -0500
          Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-11 15:15 -0800
          Re: how can i find the size of a binary file Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-12 12:43 +0200
        Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-11 14:25 -0800
    Re: how can i find the size of a binary file jacob navia <jacob@spamsink.net> - 2011-11-11 22:59 +0100
      Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-11 17:46 -0800
        Re: how can i find the size of a binary file "io_x" <a@b.c.invalid> - 2011-11-14 18:18 +0100
          Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-14 20:55 -0800
    Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-11 14:03 -0800
      Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-11 17:46 -0800
        Re: how can i find the size of a binary file Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-14 01:21 -0800
          Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-14 20:55 -0800
            Re: how can i find the size of a binary file Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-15 00:41 -0800
              Re: how can i find the size of a binary file James Kuyper <jameskuyper@verizon.net> - 2011-11-15 06:53 -0500
      Re: how can i find the size of a binary file Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-13 02:23 +0100
      Re: how can i find the size of a binary file Nobody <nobody@nowhere.com> - 2011-11-13 02:47 +0000
        Re: how can i find the size of a binary file jacob navia <jacob@spamsink.net> - 2011-11-13 08:44 +0100
          Re: how can i find the size of a binary file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-13 12:31 +0000
          Re: how can i find the size of a binary file Roberto Waltman <usenet@rwaltman.com> - 2011-11-13 10:31 -0500
          Re: how can i find the size of a binary file Nobody <nobody@nowhere.com> - 2011-11-19 07:37 +0000
            Re: how can i find the size of a binary file Kaz Kylheku <kaz@kylheku.com> - 2011-11-19 17:54 +0000
              Re: how can i find the size of a binary file Willem <willem@toad.stack.nl> - 2011-11-19 18:18 +0000
              Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-19 14:19 -0800
                Re: how can i find the size of a binary file Kaz Kylheku <kaz@kylheku.com> - 2011-11-20 01:14 +0000
                  Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-19 21:41 -0800
                    Re: how can i find the size of a binary file Kaz Kylheku <kaz@kylheku.com> - 2011-11-20 05:52 +0000
                      Re: how can i find the size of a binary file Keith Thompson <kst-u@mib.org> - 2011-11-19 22:23 -0800
          Re: how can i find the size of a binary file David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
    Re: how can i find the size of a binary file blp@cs.stanford.edu (Ben Pfaff) - 2011-11-11 14:32 -0800
      Re: how can i find the size of a binary file Barry Schwarz <schwarzb@dqel.com> - 2011-11-11 17:46 -0800
    Re: how can i find the size of a binary file Ike Naar <ike@sverige.freeshell.org> - 2011-11-11 22:41 +0000
    Re: how can i find the size of a binary file "BartC" <bc@freeuk.com> - 2011-11-13 12:32 +0000
      Re: how can i find the size of a binary file "BartC" <bc@freeuk.com> - 2011-11-13 14:56 +0000

Page 2 of 2 — ← Prev page 1 [2]

#13234

Le 13/11/11 03:47, Nobody a écrit :
> On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson wrote:
>
>> An implementation is allowed to treat a
>> binary file as if it had some implementation-defined number of null bytes
>> append to it (C99 7.19.2p3), though I don't know of any implementations
>> that actually do that.
>
> CP/M records the size of a file in sectors rather than in bytes. Text
> files are terminated by a ^Z ('\x1a') character (and this behaviour
> was inherited by DOS and then Windows).

This is not true at least for the last 20 years for MSDOS
and windows...

But well, nothing is bad when fighting the "evil empire",
sure, not even lies...

I am in no way tied to Microsoft but it "should" have gotten
through that this is no longer the case for QUITE a long time.

The behavior is still there when typing from the console,
like the Ctrl-D of unix.

But if I start telling that Unix recognizes end of file when it
finds a Ctrl-D character I will be flamed (and rightly so).

[toc] | [prev] | [next] | [standalone]

#13245

jacob navia <jacob@spamsink.net> writes:

> Le 13/11/11 03:47, Nobody a écrit :
>> On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson wrote:
>>
>>> An implementation is allowed to treat a
>>> binary file as if it had some implementation-defined number of null bytes
>>> append to it (C99 7.19.2p3), though I don't know of any implementations
>>> that actually do that.
>>
>> CP/M records the size of a file in sectors rather than in bytes. Text
>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>> was inherited by DOS and then Windows).
>
> This is not true at least for the last 20 years for MSDOS
> and windows...
>
> But well, nothing is bad when fighting the "evil empire",
> sure, not even lies...
>
> I am in no way tied to Microsoft but it "should" have gotten
> through that this is no longer the case for QUITE a long time.

You know far more about C on Windows than I do, so I'd appreciate your
input here.  I just tried this program with lcc-win32:

  #include <stdio.h>
   
  int main(int argc, char *argv[])
  {
       FILE *fp;
       if (argc > 1 && (fp = fopen(argv[1], "r")) != NULL) {
            int n = 0;
            while (fgetc(fp) != EOF)
                 n++;
            printf("n=%d\n", n);
       }
       return 0;
  }

and, when given the name of this file as argv[1],

  $ hd data
  00000000  61 62 63 0d 0a 1a 0d 0a  64 65 66 0d 0a    |abc.....def..|
  0000000d

it prints "n=4".  I.e. with your C library, fgetc returns EOF when a ^Z
is seen in this text stream.  Is this something to do with my odd setup
(I'm using a Windows emulator) or is it what you would expect to see?

> The behavior is still there when typing from the console,
> like the Ctrl-D of unix.

It's not really "the Ctrl-D of unix".  What character you may type (if
any) to signal EOF to the tty driver is configurable, so the mechanism
is quite different from how Windows used to work.  What I remember of
Windows was that the ^Z was simply passed to the running program like any
other character.  Are you saying that this is not what happens on
Windows anymore?

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#13251

jacob navia  wrote:
Nobody a écrit :

>> CP/M records the size of a file in sectors rather than in bytes. Text
>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>> was inherited by DOS and then Windows).
>
>This is not true at least for the last 20 years for MSDOS
>and windows...

Unfortunately (I consider this to be a mistake) it is still true.
The C# language still recognizes CTRL-Z as a valid EOF marker. (As
part of the language specification)
--
Roberto Waltman

[ Please reply to the group,
  return address is invalid ]

[toc] | [prev] | [next] | [standalone]

#13608

On Sun, 13 Nov 2011 08:44:32 +0100, jacob navia wrote:

>> CP/M records the size of a file in sectors rather than in bytes. Text
>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>> was inherited by DOS and then Windows).
> 
> This is not true at least for the last 20 years for MSDOS
> and windows...

It remains true to this day.

If you use fopen() to open a file in text mode (i.e. with the "t" flag, or
without the "b" flag when _fmode is _O_TEXT), a ^Z character will be
treated as an EOF marker (i.e. fgetc() will return EOF upon reading this
character).

Reference:

http://msdn.microsoft.com/en-us/library/yeby3zcb.aspx

Or you could have just compiled a 5-line test program.

[toc] | [prev] | [next] | [standalone]

#13610

On 2011-11-19, Nobody <nobody@nowhere.com> wrote:
> On Sun, 13 Nov 2011 08:44:32 +0100, jacob navia wrote:
>
>>> CP/M records the size of a file in sectors rather than in bytes. Text
>>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>>> was inherited by DOS and then Windows).
>> 
>> This is not true at least for the last 20 years for MSDOS
>> and windows...
>
> It remains true to this day.
>
> If you use fopen() to open a file in text mode (i.e. with the "t" flag, or

You don't have to use the C library to see that there is a problem. Just
use the utilities that come with Windows. I just tried this on Windows 7:
 
  C:\>copy con file
  asdf
  

Now the file has no Ctrl-Z in it. It is 6 bytes long "asdf\r\n".
So far so good, right?

But now use a binary editor to insert a ctrl-Z as the first character
of the file:
 
  C:\> type file

nothing!

  C:\> copy file con

nothing!

But if we load the file in Notepad, we see everything and the Ctrl-Z shows as a
graphical character.

These clowns still haven't figured out a consistent representation of text
files that holds across their operating system.

But then, look, the idiotic drive letter is still there, so what do you expect.

[toc] | [prev] | [next] | [standalone]

#13611

Kaz Kylheku wrote:
) But then, look, the idiotic drive letter is still there, so what do you expect.

26 different drives should be enough for everybody!

(I run into a drive letter shortage at work all the time, so yeah...)


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#13615

Kaz Kylheku <kaz@kylheku.com> writes:
> On 2011-11-19, Nobody <nobody@nowhere.com> wrote:
>> On Sun, 13 Nov 2011 08:44:32 +0100, jacob navia wrote:
>>
>>>> CP/M records the size of a file in sectors rather than in bytes. Text
>>>> files are terminated by a ^Z ('\x1a') character (and this behaviour
>>>> was inherited by DOS and then Windows).
>>> 
>>> This is not true at least for the last 20 years for MSDOS
>>> and windows...
>>
>> It remains true to this day.
>>
>> If you use fopen() to open a file in text mode (i.e. with the "t" flag, or
>
> You don't have to use the C library to see that there is a problem. Just
> use the utilities that come with Windows.
[snip]

No, but you do have to use the C library to show that there's a problem
that's relevant to the current discussion and to this newsgroup.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13622

On 2011-11-19, Keith Thompson <kst-u@mib.org> wrote:
> Kaz Kylheku <kaz@kylheku.com> writes:
>> You don't have to use the C library to see that there is a problem. Just
>> use the utilities that come with Windows.
> [snip]
>
> No, but you do have to use the C library to show that there's a problem
> that's relevant to the current discussion and to this newsgroup.

Oh go stuff it.

[toc] | [prev] | [next] | [standalone]

#13633

Kaz Kylheku <kaz@kylheku.com> writes:
> On 2011-11-19, Keith Thompson <kst-u@mib.org> wrote:
>> Kaz Kylheku <kaz@kylheku.com> writes:
>>> You don't have to use the C library to see that there is a problem. Just
>>> use the utilities that come with Windows.
>> [snip]
>>
>> No, but you do have to use the C library to show that there's a problem
>> that's relevant to the current discussion and to this newsgroup.
>
> Oh go stuff it.

So you think that this is the place to go off on a tangent about the
shortcomings of Windows?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13634

On 2011-11-20, Keith Thompson <kst-u@mib.org> wrote:
> Kaz Kylheku <kaz@kylheku.com> writes:
>> On 2011-11-19, Keith Thompson <kst-u@mib.org> wrote:
>>> Kaz Kylheku <kaz@kylheku.com> writes:
>>>> You don't have to use the C library to see that there is a problem. Just
>>>> use the utilities that come with Windows.
>>> [snip]
>>>
>>> No, but you do have to use the C library to show that there's a problem
>>> that's relevant to the current discussion and to this newsgroup.
>>
>> Oh go stuff it.
>
> So you think that this is the place to go off on a tangent about the
> shortcomings of Windows?

This is an excellent place to tell you to go fuck yourself.

[toc] | [prev] | [next] | [standalone]

#13636

Kaz Kylheku <kaz@kylheku.com> writes:
> On 2011-11-20, Keith Thompson <kst-u@mib.org> wrote:
>> Kaz Kylheku <kaz@kylheku.com> writes:
>>> On 2011-11-19, Keith Thompson <kst-u@mib.org> wrote:
>>>> Kaz Kylheku <kaz@kylheku.com> writes:
>>>>> You don't have to use the C library to see that there is a problem. Just
>>>>> use the utilities that come with Windows.
>>>> [snip]
>>>>
>>>> No, but you do have to use the C library to show that there's a problem
>>>> that's relevant to the current discussion and to this newsgroup.
>>>
>>> Oh go stuff it.
>>
>> So you think that this is the place to go off on a tangent about the
>> shortcomings of Windows?
>
> This is an excellent place to tell you to go fuck yourself.

I expected better from you.

*PLONK*

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#13682

On Sun, 13 Nov 2011 08:44:32 +0100, jacob navia <jacob@spamsink.net>
wrote:

> Le 13/11/11 03:47, Nobody a écrit :
> > On Fri, 11 Nov 2011 14:03:54 -0800, Keith Thompson wrote:
> >
> >> An implementation is allowed to treat a
> >> binary file as if it had some implementation-defined number of null bytes
> >> append to it (C99 7.19.2p3), though I don't know of any implementations
> >> that actually do that.
> >
> > CP/M records the size of a file in sectors rather than in bytes. Text
> > files are terminated by a ^Z ('\x1a') character (and this behaviour
> > was inherited by DOS and then Windows).
> 
RT-11 recorded (only) blocks of 512 (8bit) bytes, which was the sector
on most if not all hard disks (then available for PDP-11) and an
integral multiple of sector for floppies (SD 128, DD 256).

> This is not true at least for the last 20 years for MSDOS
> and windows...
> 
There are two different features here:

- MSDOS, and (thus) Windows, records size to (8bit) bytes. 

- Much software on MSDOS, and Windows, including (most? all?)
C-libraries, still treats ^Z as (premature?) EOF on a text file, even
though the underlying need for it is gone.

[toc] | [prev] | [next] | [standalone]

#13140

mark <nospam@nospam.com> writes:

> thanks for any help

I'm surprised that no one else has cited the FAQ, so far:

19.12:	How can I find out the size of a file, prior to reading it in?

A:	If the "size of a file" is the number of characters you'll be
	able to read from it in C, it is difficult or impossible to
	determine this number exactly.

	Under Unix, the stat() call will give you an exact answer.
	Several other systems supply a Unix-like stat() which will give
	an approximate answer.  You can fseek() to the end and then use
	ftell(), or maybe try fstat(), but these tend to have the same
	sorts of problems: fstat() is not portable, and generally tells
	you the same thing stat() tells you; ftell() is not guaranteed
	to return a byte count except for binary files.  Some systems
	provide functions called filesize() or filelength(), but these
	are obviously not portable, either.

	Are you sure you have to determine the file's size in advance?
	Since the most accurate way of determining the size of a file as
	a C program will see it is to open the file and read it, perhaps
	you can rearrange the code to learn the size as it reads.

	References: ISO Sec. 7.9.9.4; H&S Sec. 15.5.1; PCS Sec. 12 p.
	213; POSIX Sec. 5.6.2.

-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[toc] | [prev] | [next] | [standalone]

#13163

On Fri, 11 Nov 2011 14:32:13 -0800, blp@cs.stanford.edu (Ben Pfaff)
wrote:

>mark <nospam@nospam.com> writes:
>
>> thanks for any help
>
>I'm surprised that no one else has cited the FAQ, so far:
>
>19.12:	How can I find out the size of a file, prior to reading it in?
>
>A:	If the "size of a file" is the number of characters you'll be
>	able to read from it in C, it is difficult or impossible to
>	determine this number exactly.
>
>	Under Unix, the stat() call will give you an exact answer.
>	Several other systems supply a Unix-like stat() which will give
>	an approximate answer.  You can fseek() to the end and then use
>	ftell(), or maybe try fstat(), but these tend to have the same

From 7.19.9.2-3: "A binary stream need not meaningfully support fseek
calls with a whence value of SEEK_END."

>	sorts of problems: fstat() is not portable, and generally tells
>	you the same thing stat() tells you; ftell() is not guaranteed
>	to return a byte count except for binary files.  Some systems
>	provide functions called filesize() or filelength(), but these
>	are obviously not portable, either.
>
>	Are you sure you have to determine the file's size in advance?
>	Since the most accurate way of determining the size of a file as
>	a C program will see it is to open the file and read it, perhaps
>	you can rearrange the code to learn the size as it reads.
>
>	References: ISO Sec. 7.9.9.4; H&S Sec. 15.5.1; PCS Sec. 12 p.
>	213; POSIX Sec. 5.6.2.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#13142

On 2011-11-11, mark <nospam@nospam.com> wrote:
> [how can i find the size of a binary file]

This is a FAQ, see http://c-faq.com/osdep/filesize.html

[toc] | [prev] | [next] | [standalone]

#13246

I generally use something like this:

long getfilesize(FILE* handle){
long p,size;

#if WINDOWS

p = ftell(handle);            /* current position */
fseek(handle,0,SEEK_END);     /* get EOF position */
size = ftell(handle);         /* size in bytes */
fseek(handle,p,SEEK_SET);     /* restore original position */
return size;

#else

 puts("Sorry this system doesn't support quick file-size reporting");
 exit(0);
 return 0;
#endif
}

Notes:

o I've restricted this to work only for Windows, so WINDOWS must be set to 1
or 0 somewhere. You might try taking out this check to see what happens.

o The file must be open to determine the size

o If the system isn't Windows, or one where these calls will work, you can
try alternate code such as reading byte-by-byte; that will be slow but it
could work.

o The fseek() and such functions return an error code which I haven't
bothered to check (as I don't have error handling in this function)

o The functions I used are restricted to the range of 'long' (which I think
is 2GB in this case); I don't know what happens above 2GB, and don't have
files that big to test on. However being restricted to Windows, that could
have 64-bit versions available, as well as specialist functions which are 
part of the OS rather than C.

o Making use of fstat() is also possible, but that is also frowned on here
so makes no difference.

o A file size of course could conceivably change by the time it is acted on.
But a file can also be deleted between calling fopen() and checking the
return value. So you can either give up programming right now, or just bear
these possibilities in mind.

o If I was interested in making this portable I might use a series of 
#if/#elif checks for a range of platforms with appropriate code for each, 
followed by an #else clause with some default code. But I'm not, and it 
would probably turn out to be impossible anyway. So I don't worry about it.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#13250

"BartC" <bc@freeuk.com> wrote in message news:j9odfc$umt$1@dont-email.me...


> o A file size of course could conceivably change by the time it is acted 
> on.
> But a file can also be deleted between calling fopen() and checking the
> return value.

Actually that might not be possible anymore (on Windows). But I believe 
almost else anything can be done to the file, including deleting the entire 
contents.

-- 
Bartc 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web