how can i find the size of a binary file

[Roberto Waltman]

jacob navia wrote:
Nobody a écrit :

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)

 

[Nick Keighley]

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

why do you keep doing this? What is your point?

<snip>

 

[Barry Schwarz]

why do you keep doing this? What is your point?

People keep recommending an approach which may or may not work and for
which there is no requirement that the implementation document whether
it does or not. I'm pretty sure the OP has long abandoned the thread
but it would be a disservice to those who follow the frequent advice
to search the archives to allow a questionable recommendation to stand
without some qualification.

 

[Barry Schwarz]

i agree with Barry Schwarz on above.
on "How can the user determine this?" : the user can find the second time
the size is the same: if it is the same ok copy in the other case return error.
the wrong is i know what contain file in the time t° but not in the time t'>t°
and suppose no change of file for time >t°.

Your response makes no sense. What second time?

The point I was trying to make was that one should examine the return
from fread.

 

[Nick Keighley]

did you miss the "*usually*"?

People keep recommending an approach which may or may not work

so saying it once seems fine.

and for
which there is no requirement that the implementation document whether
it does or not.

but i also suspect it works on very many systems. Unix and Windows?

 

[James Kuyper]

so saying it once seems fine.

Once per contrary recommendation, yes. Doing it only once in a thread
where the same recommendation has been made multiple times might not be
sufficient warning for people who are only skimming the thread.

 

[Nobody]

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.

 

[Kaz Kylheku]

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.

 

[Willem]

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

 

[Keith Thompson]

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.

 

[Kaz Kylheku]

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.

 

[Keith Thompson]

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?

 

[Kaz Kylheku]

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 **** yourself.

 

[Keith Thompson]

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 **** yourself.

I expected better from you.

*PLONK*

 

[David Thompson]

Le 13/11/11 03:47, Nobody a écrit :

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.