[Mono-bugs] [Bug 78230][Nor] Changed - Access Denied error related to deleting and accessing of .CS files generated during XmlSerialization object creation from multiple threads/processes on the same machine

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by apasumarthi at alliance-consulting.com.

http://bugzilla.ximian.com/show_bug.cgi?id=78230

--- shadow/78230	2006-05-04 07:21:14.000000000 -0400
+++ shadow/78230.tmp.12756	2006-05-04 07:25:11.000000000 -0400
@@ -131,6 +131,31 @@
 Generating /tmp/26350.cs
 
 It means that a serializer is being generated in that file. It would
 be interesting to see which files are generated when you get the
 error. If two serializers are generated with the same file name, then
 something may be wrong with unique temp file creation.
+
+------- Additional Comments From apasumarthi at alliance-consulting.com  2006-05-04 07:25 -------
+You are right the whole issue is with the unique temp file name 
+generation. I have been stressig this point from the first message.
+
+I described how to run the sample code also. Run multiple processes 
+immediately and you will see the exception.
+
+It fails on LINUX (RHEL 3) also. And, apart from LINUX, I want 
+XmlSerializer to work reliably on Windows also.
+
+Lluis, issue is obvious from the bug #76125. XmlSerializer is using 
+temp file names randomly generated without seeing if the file with 
+that name is already in use. This is a serious flaw as it would cause 
+exception when multiple instances of the same process is running on 
+the same system. 
+
+We _need_ some unique name generation mechanism for these temp files. 
+otherwise applications like that of mine cannot run reliably on MONO 
+runtime and obviously cannot be cross-platform compatible. I want to 
+stress the point that the same applications (both sample and my 
+original server) runs reliably and flawlessly on MS.Net runtime.
+
+Guys, please look at the core of the issue, the temp file name 
+generation and its usage for creating temp .CS files by XmlSerializer.