Strange Problem at writing file
-
Ah, just looked like you did. is this being done in < .NET 2.0?
-Spacix All your skynet questions[^] belong to solved
-
Ah, just looked like you did. is this being done in < .NET 2.0?
-Spacix All your skynet questions[^] belong to solved
-
Are you using the old xmlreader and xmlwriter? If not then why do you "open, read, close" then "open, write, close" ?
-Spacix All your skynet questions[^] belong to solved
-
Are you using the old xmlreader and xmlwriter? If not then why do you "open, read, close" then "open, write, close" ?
-Spacix All your skynet questions[^] belong to solved
-
I'm using the xmlDocument Class. When i want to save with xmlDocument.save() that error happens
Im willing to bet that you've not disposed properly of the stream when you open the file, hence when you come to write it there is already another process holding onto it (ie, your own program from earlier on during the read op)
-
Im willing to bet that you've not disposed properly of the stream when you open the file, hence when you come to write it there is already another process holding onto it (ie, your own program from earlier on during the read op)
-
I'm using the xmlDocument Class. When i want to save with xmlDocument.save() that error happens
once you call the load() method the file should no longer be accessed... Again I don't see why you "open, load, close" then "open, write, close" You should be fine with it in ram after you load it. "open, load" do your other stuff "append new data, close"
-Spacix All your skynet questions[^] belong to solved
-
once you call the load() method the file should no longer be accessed... Again I don't see why you "open, load, close" then "open, write, close" You should be fine with it in ram after you load it. "open, load" do your other stuff "append new data, close"
-Spacix All your skynet questions[^] belong to solved
-
I tried it. But it doesn't have an effect. Here is my code at the moment:
//some loop
XmlDocument doc = new XmlDocument();
doc.Load(FullFilePath);
.......//do sth.
doc.Save(FullFilePath); //<-There the error happens
//end of loopDoes it error if you try to write to a different file path? (one you know you have write access to)
-Spacix All your skynet questions[^] belong to solved
-
I tried it. But it doesn't have an effect. Here is my code at the moment:
//some loop
XmlDocument doc = new XmlDocument();
doc.Load(FullFilePath);
.......//do sth.
doc.Save(FullFilePath); //<-There the error happens
//end of loopHi, if you want write or delete access (anything other than read access) to a file that just got created (by yourself or someone else, does not matter), chances are you will find the file is being accessed by some other process, and your access is not granted. Yhe other process very likely is some server code that is there to assist you somehow. Candidates are: - anti-virus software (Norton, McAfee, whatever) - indexing software (Google Desktop, MS Office, whatever) The common thing is these packages are looking all the time for new files, so they can inspect them. Microsoft is aware of the consequences; Windows Explorer will try rename and delete attempts up to five times (with one second interval), and only reports failure if the action continues to fail for that time. The solution: 1. either use a different file name 2. or remove all background reader candidates (bad idea) 3. or implement the retry loop as Explorer has it (use a Windows.Forms.Timer for this) :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
-
Hi, if you want write or delete access (anything other than read access) to a file that just got created (by yourself or someone else, does not matter), chances are you will find the file is being accessed by some other process, and your access is not granted. Yhe other process very likely is some server code that is there to assist you somehow. Candidates are: - anti-virus software (Norton, McAfee, whatever) - indexing software (Google Desktop, MS Office, whatever) The common thing is these packages are looking all the time for new files, so they can inspect them. Microsoft is aware of the consequences; Windows Explorer will try rename and delete attempts up to five times (with one second interval), and only reports failure if the action continues to fail for that time. The solution: 1. either use a different file name 2. or remove all background reader candidates (bad idea) 3. or implement the retry loop as Explorer has it (use a Windows.Forms.Timer for this) :)
Luc Pattyn [Forum Guidelines] [My Articles]
this weeks tips: - make Visual display line numbers: Tools/Options/TextEditor/... - show exceptions with ToString() to see all information - before you ask a question here, search CodeProject, then Google
Thank you very much.
Luc Pattyn wrote:
The solution: 1. either use a different file name 2. or remove all background reader candidates (bad idea) 3. or implement the retry loop as Explorer has it (use a Windows.Forms.Timer for this)
1. and 2. are no solutions for me. I have to try 3. I think. I hoped i don't have to use a timer :(