[Mono-list] Differing behaviour of XmlDocument.Save(String) on Linux and Windows

[Atsushi Eno]

Hello,

> This code works fine on both windows and linux, spite the fact when the
> same filename is given to the loading method and the saving method. On
> linux, this works fine, the Save() overwrites the old file with a new
> file. On Windows however an exception is thrown telling me a sharing
> violation had occured. MS .Net showed the same behaviour, not allowing
> me to write to the same file if I had opened it with my load method
> above. I do not have the experience of deciding if this is a bug or not
> on the mono-linux side, or just a rude programming fault on my side. 

Hmm, this does not happen to my fedora core 2 box. It raises
file sharing error. Which version of mono are you using?

When you open a file via XmlTextReader, it is locked until you
explicitly call Close(). Thus, the file sharing error should be
thrown, since you are keeping the file opened.

> (OT now, sorry) Does anyone know an elegant way of loading an
> XmlDocument and then writing the updated contents back into the same
> file? 

Once you read up the source xml into XmlDocument, the input file can
be used (by calling Close()).

> Next to the problem with XmlDocument, if I dump a DateTime Object to a
> string with ToString("F") on Linux and read that dumped string back into
> a windows box with DateTime.Parse(string) I get an FormatException. 

In which culture are you living? The line below will provide you the
exact information.

Console.WriteLine (System.Globalization.CultureInfo.CurrentCulture);

We could not support all the culture and it may differ if IBM icu
defines different culture data. Right now CultureInfo.InvariantCulture
should work fine.

> DateTime.Now.ToString("F"); produces 
> "June 15, 2004 7:44:07 P +2" on Linux (RH9) 
> and the same produces 
> "June 15, 2004 7:55:07 +2" on Win32 (without the 'P') 

Maybe you are in different culture when you are using those machines.


Atsushi Eno