Whats and How to End Of File Data.

I was hoping someone could explain something for me.
Apparently there are some files that need some sort of end of file data (EOF).
To run uncorrupted I was wondering what is this data and how do I preserve it when reading a file using the Win32 API? I Found SetEndOfFile(_In_ HANDLE hFile); http://msdn.microsoft.com/en-us/library/windows/desktop/aa365531(v=vs.85).aspx

On MSDN there is a example but this only seem to check if the file was read to the end (Not the data presiding the "end".) like so.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365690%28v=vs.85%29.aspx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
int _tmain(int argc, _TCHAR* argv[])
{

	cout << "ENter File Name: ";

	string fileName;
	getline( cin, fileName );
	cout << "Opening File..." << endl;
	HANDLE hFile = NULL;
	hFile = CreateFile(fileName.c_str(), GENERIC_READ,
                           0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, hFile);
	if ( hFile == NULL )
	{
		cout << "Failed to open file " << fileName << endl;
		cout << "Error Code: " << GetLastError() << endl;
		system("PAUSE");
		return 0;
	}

	DWORD dwFileSize = GetFileSize( hFile, &dwFileSize );
	char *pFileBuf = new char[dwFileSize];
	DWORD dwByteRead = 0;
	BOOL bSuccess = false;
	if ( !ReadFile( hFile, (LPVOID)pFileBuf, dwFileSize, &dwByteRead, NULL) )
	{
		cout << "Failed to ReadFile file " << fileName << endl;
		cout << "Error Code: " << GetLastError() << endl;
		system("PAUSE");
		return 0;
	}
	if ( bSuccess && dwByteRead == 0 )
	{
		cout << " at the end of the file" << endl;
	} else { cout << "No eof data..." << endl; }

	cout << "Done reading file..." << endl;
	CloseHandle(hFile);
	system("PAUSE");
	return 0;
}


Would anyone be so kind to explain this concept for me, I very much appreciate it.
EDIT: Or do the complete buffer with the end of file data (EOF) get copyed. since as far as i understand the GetFileSize() http://msdn.microsoft.com/en-us/library/windows/desktop/aa364955%28v=vs.85%29.aspx
Returns the size in bytes witch is the size of the file on disk (witch gets rounded up, if the number is not whole.).
Is this where the EOF data is places/ stored? Or am i just wrong?

Thanks
WetCode
Last edited on
Don`t anyone here know what this is, or am I so misinformed that it don't make any sense?
EDIT: After reading this http://stackoverflow.com/questions/16677632/what-really-is-eof-for-binary-files-condition-character
And this http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1048865140&id=1043284351

Am even more confused from what I originally thought is that some data was written after the EOF "character". But after reading the links above am just under the impression that EOF means exactly that (This is the End Of File no more data here.)

So when someone says is dependent on the EOF to run what those this mean?
Last edited on
Back in the old days (of magnetic tape), an EOF character (26) was placed in the stream to indicate end of file. But that's not really used anymore.

Multics introduced the notion of a file stream. It got inherited by Unix and is now ubiquitous. What we care about it End Of Stream. An EOF character, char 26, is just treated as data.

I was wondering what is this data and how do I preserve it when reading a file
You open the file in binary mode and treat char 26 as the EOF marker and stop.

http://stackoverflow.com/questions/16677632/what-really-is-eof-for-binary-files-condition-character
This is trying to explain the difference between the End Of File character in the file with the End Of Stream status of the stream. EOF is a constant that indicates the file as reached the end and is now in the End Of Stream state.

http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?answer=1048865140&id=1043284351
This is saying that when EOF is encountered, it means End Of Stream.

All of those MSDN references are taking about End Of Stream, not the EOF character in the file.
Snip From: http://stackoverflow.com/questions/16677632/what-really-is-eof-for-binary-files-condition-character
One could, however, have an implementation in which the raw data in the file contains something that indicates the end of file, but data is transformed when reading or writing so that arbitrary data can be stored. (E.g., by “quoting” the end-of-file marker.)


If the data is not placed in
So in theory I can "hide" data in the file that only gets read if you are accounting for the Quotes of EOF markers in a file??
i.g: " Raw Data as a string" or in essence it can be EOF Raw Data as end of file data EOF ?
Any confirmation would be nice its very interesting if it works like that though.
But am I am not share since am under the impression that any data in a file is always stored in a section in the IMAGE_SECTION_HEADER of the PE file.
So many questions on such a seemingly simple thing, any thoughts?
Last edited on
I canmot see what's confusing or
questionable.

And what does this have to do with PE
What am asking is and am only speculating trying and to understand that's all.
The PE headers / sections contain variable data, execution code and so 4th.
So way would you use the EOF makers/ "character" to quoting in data at the end of a file do you use it at runtime for something?

As I sad am just interested in learning new things about programming but am not a expert like some people on here. So am sorry if I tend to ask some stupid questions.
I try to put in the effort before asking, but sometimes its just a good idea to ask someone.

Cheers
WetCode.
I wasn't aware the the PE format had EOF markers. If that's the case, then they're just data. They don't indicate End Of File. That should be obvious as the loader has to read past these alleged markers to get to the next section, right?
I think you are right I will try to get some code together and see if I can find a program that have the EOF marker in one of the PE sections and see what its used for / what happens when I read the section.

I guess I would have to make a prototype of the loader and read/write and relocate the sections manually to really get a picture of what happening. I`le keep you posted if anyone is interested.
If you're writing your own program, it'll just do whatever you've instructed it to do. So you won't deduce anything from doing that.

However, if you want to experiment with such things for some other reason, such as to modify a PE file prior to execution, then that's fine.

For example, when PE was new, a colleague discovered an article describing the significance of the base address of a PE DLL. She wrote an app to graphically show address conflicts/free blocks and rebase these DLLs for a given set of executables. That can only be done by reading/editing the PE files directly.
Topic archived. No new replies allowed.