Re: who to use fwrite to write through a hidden file
- From: Joseph M. Newcomer <newcomer@xxxxxxxxxxxx>
- Date: Sun, 01 Jul 2007 14:56:06 -0400
To say that this is dangerous in the extreme is to understate the situation. If you mess
up boot.ini, the machine is rendered unbootable.
See below...
On Mon, 25 Jun 2007 20:13:00 -0700, Hayes <Hayes@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
hi all~*****
now i try to use "fgets" and "fwrite" to read and modify a hidden file
"boot.ini"
code :
file = fopen("C:\\"boot.ini", "rt");
CStdioFile file;
if(!file.Open(_T("c:\\boot.ini"), CFile::modeRead))
return;
I notice you did not actually check to see if the open succeeded; it is VERY important
that you do so!
******
*****
while( fgets(data, 512, file) != NULL )
{ content[row++].Format("%s", data); }
fclose(file);
DUH! And what part of "assigning a string" have you missed? Why do you take a string,
format it as a string, and store it when the obviously correct way is to write
content[row++] = data;
really simple, always works.
For that matter, why did you not write
file.ReadString(content[row++)];
which would have been even easier!
*****
****
if( content[row-1].Find( " /noguiboot /bootlogo" ) != -1 )
{
content[row-1].Replace(" /noguiboot /bootlogo", "");
file = fopen("C:\\text.txt", "wt+");
This code is more than a little suspect. It only checks one line, the last line, and that
makes no sense. It opens a file, and NEGLECTS TO SEE IF THE OPEN WORKED! Why would you
presume that it worked? You have no reason to assume this could work.
Why w+, which opens it for reading and writing? Why not just w? And note that the
contents are DESTROYED, which means that if your program were to fail for any reason, the
system has just become unbootable.
Allowing a piece of code like this to exist is exceptionally deadly, and it is so poorly
written that there is no guarantee that it would actually write out a usable boot.ini
file.
This is where things get REALLY dangerous! If you fail in the middle of this, the user is
totally screwed, and I mean TOTALLY screwed! Nothing short of a reinstall of Windows is
going to save the user.
Why do you want to turn off the custom-boot logo anyway? If someone set up a custom-boot
logo, why do you presume that you have the right to change it? Please justify your
rationale here.
Let me put it this way: I would not consider writing such a piece of code. It is FAR, FAR
too dangerous to have a program that does this, and although I could actually write a
piece of code vastly more reliable than this, I would not consider it a reasonable thing
to consider doing. (I would do it as a memory-mapped file, and probably just overwrite
the switches with spaces so that I made the minimum number of changes possible, thus
meaning that no matter where there was a failure mode the file would be left intact and
usable). But I would never, ever, under any situation imaginable, EVER open boot.ini in a
way that erased the contents. That line is the most dangerous line of code I have seen
posted in many years.
[It was 1968. A fellow graduate student wrote a piece of code that opened the OS/360
equivalent of the master file directory just to see if he could. He could. So he
wondered if it was possible to open it for writing. It was. He wrote a program that
"harmlessly" opened-and-closed the file. Of course, it destroyed the contents and our
entire mainframe went down for about six hours. He was very nearly thrown out of school
for it, until he convinced people there was no malice intended. This piece of code
reminds me of that incident. I was one of the people who testified in his favor to the
faculty investigation committee, because he had told me--and a few others--of the first
part of his intended experiment.]
Note that this will have no applicability to Vista and beyond, since Vista does not use
boot.ini, so whatever you do is going to be useless in the future.
Why do you presume that the line you want to change is the last line in the boot.ini?
There is no reason to expect this line to be the last line, and in a multiboot environment
it quite likely will NOT be the last line, so again, you can render the entire system
unbootable if you make a mistake. Or, this code will simply have no effect because the
last line won't be the one you want to change.
*****
int line = 0;****
while(line != row)
{
** fwrite(content[line], sizeof(char), content[line].GetLength(), file);
line++;
for(int line = 0; line < content.GetSize(); line++)
file.WriteString(content[line]);
you have written a complex test for a simple situation, and furthermore you have made
assumptions about the structure of boot.ini that are true only in the one example you have
looked at. My boot.ini is quite a bit more complex and your program would fail for such a
case.
But the whole notion of rewriting boot.ini is one of the scariest ideas I've seen in a
long time. Don't do it. Don't even try. If you can't do it as a memory-mapped file with
in-place removal and nothing else, don't even go there. A program failure should result
in your being sued out of existence by anyone whose machine was rendered unbootable, and
I'd be happy to volunteer as expert witness to testify that such a piece of code was
professionally irresponsible.
*****
}****
fclose(file);
}
if i set the file be hidden,
and i get a error on line **
the merror essage --
"Microsoft Visual Studio C Runtime Library has detected a fatal error in
*.exe"
If you had actually entered the debugger, you would probably have discovered that the file
pointer was NULL, because the file had failed to open, most likely because it is read-only
and you were attempting to write to it. Note that there is no reason to assume that an
fopen worked, but you have certainly assumed that here, so OF COURSE you will get some
off-the-wall error caused by using incorrect information.
I cannot state too strongly that this code should never exist. It is the wrong approach,
and it is so dangerous that an expert such as myself would thing twenty or thirty times
about ways to avoid ever trying to programmatically modify boot.ini, and do everything in
my power to make sure I never needed to do this. Only an amateur would even consider a
program this badly designed as a possibility, and you clearly are a naive beginner, as
evidenced by your total failure to even check an fopen to see if it worked! Don't do
something like this until you understand what you are doing! Right now, you are so
totally clueless about the consequences of your code that you couldn't even write the
simplest error checks into it; how can you be trusted to modify something as critical as
boot.ini at all?
I know the real reason you are having problems, but frankly, I'm not going to tell you
until I see a piece of code I know I could trust, and I don't see that here. You have not
proven to me that you are capable of using the answer responsibly. This code is the work
of someone who has no clue how to write reliable code, and nonetheless is attempting to
modify one of the most critical files in the system by using code I would fail a freshman
for writing. As the third assignment. (Well, maybe as the fourth assignment).
*****
*****
I don't know what to do to resolve it.
maybe something's wrong..
What is wrong is that you are completely clueless. Someone who has your demonstrated
skill level should not be writing code to modify boot.ini. Once you have learned the
fundamental concepts of programming, ask again.
joe
*****
thanks for help~Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.
- Prev by Date: Memory corruption and Dump Stack trace
- Next by Date: Re: fwrite a hidden file
- Previous by thread: Memory corruption and Dump Stack trace
- Next by thread: Re: fwrite a hidden file
- Index(es):
Relevant Pages
|
