[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | Microsoft Windows 95 ("Chicago") |
| Notice: | Please read topics 1 to 22 before writing anything |
| Moderator: | EEMELI::BACKSTROM |
|
| Created: | Mon Nov 14 1994 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2958 |
| Total number of notes: | 19968 |
2759.0. "Why hex 1A ends some of FAT text files?" by CPEEDY::WANG () Fri Jan 24 1997 15:48
I have a bit of problem and hope anyone can help with...
On a FAT volume (W95 or WNT), if I created a file 33 bytes
long, the DOS dir command will show its size is 33.
When I copy this file to another new file, the new file
is expected to have the same size. Once in a long while,
the detination file will be one byte longer (34). The
extra byte at the end is a hex 1A.
Since this case is not always easy to reproduce, I find
a new way to see that extra byte ....
If I concatenate any two FAT files, the resulted file is
always one byte longer than expected file size. For exmaple,
it would be 33+33=67. That 1A byte is at the EOF.
What is the problem? The problem is: if 1A is used as EOF
mark for FAT file, why it does not appear in a newly created
FAT file, or when a file is single copied? Also, why
single copy (not concatenation) do produce longer file
sometimes?
I would also appreciate pointer to detail doc on FAT file
organization.
Thank you for any input.
Grace
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2759.1 | | GUIDUK::MCCANTA | | Tue Jan 28 1997 19:10 | 5 |
| When you copy the files, try using the /B switch. That means that you
are transferring binary data to a binary file. DOS won't try to add
the text EOF to the end of it. If the file is all printable chars for
the first 80(?) chars, DOS assumes it is a text file and ends it with
the EOF .
|