Re: EOF location?


"HeyBub" <heybubNOSPAM@xxxxxxxxx> wrote in message
news:127hfdman9s836f@xxxxxxxxxxxxxxxxxxxxx
Anyone know where the EOF is supposed to be located on a PC file?


Er...please sir! please sir!... at the END of the file, sir!

In other words, if Windows reports a file is, say, 100 bytes long, is the
EOF (X'1A') supposed to be in the 100th or 101st byte?


I did a quick experiment using a DOS box....

Here's the results... (I have added comments for those who were not born
when the only option was a command line interface...these comments (as this
is a COBOL forum) are prefixed with *>

================== start of DOS box ===============

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

*> Create a simple text file with the characters 1 thru 8...

C:\Documents and Settings\dashwood>echo 12345678 > testfile.txt

*> Make sure that textfile.txt DOES contain the expected characters...

C:\Documents and Settings\dashwood>type testfile.txt
12345678

*> Get a directory report on the file...

C:\Documents and Settings\dashwood>dir testfile.txt
Volume in drive C is PetesP4system
Volume Serial Number is D499-5305

Directory of C:\Documents and Settings\dashwood

28/05/2006 17:07 11 testfile.txt
1 File(s) 11 bytes
0 Dir(s) 10,042,187,776 bytes free

It would appear that there are three more characters than we actually input.

Windows reports the file as 11 bytes; yet only 8 characters were input...

Looks like a job for Hex Editor...(AXE version 3 ...)

31 32 33 34 35 36 37 38 20 0d 0a

Aha! NINE characters were input; I inadvertently entered a space... (x20)

So, the answer to your question:

YES, the two characters which indicate EOF (in the Windows environment) ARE
included in the file size reported by the Operating System. Your Hex 1F EOF
is incorrect for a text file (possibly COBOL uses a different EOF, but I
doubt it); it is x'0D' x'0A' and both these characters ARE INCLUDED in the
size reported by the OS.


I've got copy books with both conditions and I suspect this inconsistency
is screwing up PowerCOBOL's "#INCLUDE" commands. (I suspect this because I
get the dreaded "...error in .SVD file according to INCLUDE or COPY
turnip...")

Fell into the old PowerCOBOL #include trap, huh :-)... best avoided. I used
it for a while then completely scrapped it.

Diligent research reveals I've got 107 copy books of which 33 have the EOF
beyond the size reported by Windows and 74 files where the
Windows-reported length includes the EOF.

And shouldn't a copy book end with a CR or LF?

As you can see from the above, it does...

HTH,

Pete



.

Relevant Pages

  • Re: EOF location?
    ... Sorry PD, CR/LF has never, and will never indicate EOF. ... Modern windows "command window" do NOT insert ... It would appear that there are three more characters than we actually ... Copying a console stream is NOT the same thing at ...
    (comp.lang.cobol)
  • Re: EOF location?
    ... I was confusing EOR with EOF in a line sequential file. ... EOF in modern windows systems is recognised from the file size ... *> Create a simple text file with the characters 1 thru 8... ...
    (comp.lang.cobol)
  • Re: EOF location?
    ... at the END of the file, sir! ... It would appear that there are three more characters than we actually ... Windows reports the file as 11 bytes; ... the two characters which indicate EOF (in the Windows ...
    (comp.lang.cobol)
  • Re: Long path exploit on NTFS
    ... can take up to 32.000 characters. ... Vunerability report: ... Windows NT 4.0 SP6a ...
    (Bugtraq)
  • Re: EOF location?
    ... *> Get a directory report on the file... ... It would appear that there are three more characters than we actually ... the two characters which indicate EOF ... An ASCII CRLF pair are actually "line separators" used to ...
    (comp.lang.cobol)