XML deserializer sees zero-length file, "root element is missing"

[MC]

I have a couple of customers who are using a program that deserializes an
XML file, and on some files, the program fails to see the content of the
file -- treats it as zero length and reports "root element is missing" --
even though in Notepad the file looks normal.

Has anybody ever seen this? Any clues? I have not been able to reproduce
it on my computer. In general, when they e-mail me the files, the files
arrive perfectly normal. But on one occasion the e-mailed files were
zero-length.

Thanks!

[Paul E Collins]

"MC" <fo**************@www.ai.uga.edu.slash.mcwrote:

I have a couple of customers who are using a program that deserializes
an XML file, and on some files, the program fails to see the content
of the file -- treats it as zero length and reports "root element is
missing" -- even though in Notepad the file looks normal.

Could it be a file permissions issue?

Eq.

[Peter Duniho]

On Wed, 23 Apr 2008 06:41:52 -0700, MC
<fo**************@www.ai.uga.edu.slash.mcwrote:

I have a couple of customers who are using a program that deserializes
an XML file, and on some files, the program fails to see the content of
the file -- treats it as zero length and reports "root element is
missing" -- even though in Notepad the file looks normal.

Has anybody ever seen this? Any clues? I have not been able to
reproduce it on my computer. In general, when they e-mail me the files,
the files arrive perfectly normal. But on one occasion the e-mailed
files were zero-length.

If the user was able to actually show you a zero-length file at least
once, that makes me suspicious that the other files that aren't
zero-length are not in fact the actual file that was being read. This
could be because the user provided the wrong file, or because you've got
some sort of race condition in which the files were zero-length when your
program tried to read them, but not when the user looked at them later.

How are the files being generated?

Pete

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

Does your program actually check to see that it is about to deserialize a
well-formed xml document? And handle this expected condition properly? I
realize this may seem obvious...

-- Peter
To be a success, arm yourself with the tools you need and learn how to use
them.

Site: http://www.eggheadcafe.com
http://petesbloggerama.blogspot.com
http://ittyurl.net
"MC" wrote:

I have a couple of customers who are using a program that deserializes an
XML file, and on some files, the program fails to see the content of the
file -- treats it as zero length and reports "root element is missing" --
even though in Notepad the file looks normal.

Has anybody ever seen this? Any clues? I have not been able to reproduce
it on my computer. In general, when they e-mail me the files, the files
arrive perfectly normal. But on one occasion the e-mailed files were
zero-length.

Thanks!

[Michael A. Covington]

"Paul E Collins" <fi******************@CL4.orgwrote in message
news:Hp******************************@bt.com...

"MC" <fo**************@www.ai.uga.edu.slash.mcwrote:

>I have a couple of customers who are using a program that deserializes an
XML file, and on some files, the program fails to see the content of the
file -- treats it as zero length and reports "root element is missing" --
even though in Notepad the file looks normal.

Could it be a file permissions issue?

Conceivably. If so, the right exception is not being thrown.

One other clue. Normally, when the customer e-mails me the un-openable
files, they look normal and open just fine in my copy of the software.
Today, however, I was sent two of them which arrived as zero-length files.
So Outlook, or whatever they sent their mail with, had the same problem as
my program trying to open the files.

[Michael A. Covington]

If the user was able to actually show you a zero-length file at least

once, that makes me suspicious that the other files that aren't
zero-length are not in fact the actual file that was being read.

Good point.

>This could be because the user provided the wrong file, or because you've
got some sort of race condition in which the files were zero-length when
your program tried to read them, but not when the user looked at them
later.

How are the files being generated?

The program is basically for creating and editing files containing a large
data structure.

Loading a file looks like this:

using (StreamReader infile = new StreamReader(new FileStream(filename,
FileMode.Open, FileAccess.Read, FileShare.Read)))
{
XmlSerializer x = new XmlSerializer(this.GetType());
foo j = (foo)x.Deserialize(infile); // foo stands for the name of my
big class
infile.Close();
}

Saving a file looks like this:

using (StreamWriter outfile = new StreamWriter(filename))
{
XmlSerializer x = new XmlSerializer(this.GetType());
x.Serialize(outfile,this);
outfile.Close();
}

Since the loading and saving are done at different times (at least minutes
apart) by the same person, I don't see how it could be a race condition.

Is there some error condition that could result in a zero-length file
(either reading or writing) without throwing an exception?

[Michael A. Covington]

"Peter Bromberg [C# MVP]" <pb*******@yahoo.NoSpamMaam.comwrote in message
news:4C**********************************@microsof t.com...

Does your program actually check to see that it is about to deserialize a
well-formed xml document? And handle this expected condition properly? I
realize this may seem obvious...

See other posting. I'm not quite sure what you mean. I use
XmlSerializer.Deserialize. But the next step is going to be to add some
code that first opens the file and looks at it (to verify that it exists and
isn't empty) before letting the serializer work.

[Peter Duniho]

On Wed, 23 Apr 2008 14:52:44 -0700, Michael A. Covington
<lo**@www.covingtoninnovations.com.for.addresswrot e:

[...]
Since the loading and saving are done at different times (at least
minutes
apart) by the same person, I don't see how it could be a race condition.

I don't either. But then, the above is of course a simplification of
what's really going on. It could be that with a concise-but-complete code
sample, an actual problem could be identified. Of course, I suspect that
if you had such a sample and you knew how to get it to misbehave, you
wouldn't be asking the question. :)

Is there some error condition that could result in a zero-length file
(either reading or writing) without throwing an exception?

I should hope not. I admit, I don't know with 100% certainty, but my
approach to an OS API, Windows included, is that it will do exactly what I
tell it to, unless it tells me otherwise. No error implies it completed
the operation I asked for.

The problem has some characteristics of failing to properly flush/close
your output stream, but a) that doesn't explain why the file would show up
with data later on (i.e. when the user goes to email the file to you), and
b) at least in the simplified version you posted, everything appears to be
fine with respect to making sure the output stream is closed.

So I guess I'm out of guesses. Sorry.

One thing you might try is delivering a version of your program with some
instrumentation in it. Have it log user actions, and perhaps also do some
double-checking when the file's written to make sure it winds up the
length you expect (i.e. 0). Heck, you might even write to a
MemoryStream instead, and then do some verification on the length of the
resulting string, as well as making sure that the file written matches the
length and contents of the MemoryStream. That way the file i/o has some
double-checking in it.

Other than that, it's pretty much a mystery to me. :)

Pete

[MC]

Latest development: The problem seems to be with the program WRITING
zero-length files, not READING them, and earlier, when the customer sent me
"unopenable" files that opened just fine, I'm thinking they were the wrong
files. (Not 100% sure though.)

using (StreamWriter outfile = new StreamWriter(filename))
{
XmlSerializer x = new XmlSerializer(this.GetType());
x.Serialize(outfile,this);
outfile.Close();
}

Is there any way this could produce a zero-length empty file without
throwing an exception?

[Paul E Collins]

"MC" <fo**************@www.ai.uga.edu.slash.mcwrote:

>using (StreamWriter outfile = new StreamWriter(filename))
{
XmlSerializer x = new XmlSerializer(this.GetType());
x.Serialize(outfile,this);
outfile.Close();
}

Is there any way this could produce a zero-length empty file without
throwing an exception?

Is it running on the main GUI thread? If not, and if the *other* thread
doesn't handle exceptions, anything that is thrown may just silently
terminate the thread.

Eq.

[MC]

Thanks, Pete. My latest thinking is that Microsoft (on
support.microsoft.com) has acknowledged some problems with System.Xml.dll
and there have apparently been some buggy versions of XmlSerializer. I'm
guessing that the two sites where the program misbehaves are sites with one
of the bad versions of that file. So I'm going to urge everyone to do a
Windows Update.

[MC]

"Paul E Collins" <fi******************@CL4.orgwrote in message
news:6q******************************@bt.com...

"MC" <fo**************@www.ai.uga.edu.slash.mcwrote:

>>using (StreamWriter outfile = new StreamWriter(filename))
{
XmlSerializer x = new XmlSerializer(this.GetType());
x.Serialize(outfile,this);
outfile.Close();
}

Is there any way this could produce a zero-length empty file without
throwing an exception?

Is it running on the main GUI thread? If not, and if the *other* thread
doesn't handle exceptions, anything that is thrown may just silently
terminate the thread.

Good thought, but the app is not multi-threaded.