Re: My windows giveth xml and it taketh away! Include path!

Nope Windows will not touch the file. My guess is your screen saver is
writing to the file on shutdown and clobbering the updated values that way?

If you just call it .xml then you won't conflict with the special magic
..config files. .config files are meant for management of the deployment of
an app, it's for the IT guys to mess with and your app usually just reads
them. So settings that your app actually saves would be in a separate file.

"Garry Freemyer" <garryfre@xxxxxxxxxxxxxxxxxxx> wrote in message
news:OrBuHPTaFHA.4000@xxxxxxxxxxxxxxxxxxxxxxx
>I wrote a screensaver, via Visual Studio 2003 in C# and I decided a wiser
>choice for me was to use an xml file to save my configs. Btw: I wonder if
>this is why every bit of documentation I've found for saving configuration
>info in an xml file speak of only doing this for web programming in fact, I
>get the impression that they have been slipped a mickey that made them
>forget that there are programs out there that are not web based, but I
>digress ...
>
> I could have done a regular config files be just a regular text file, but
> I figured, I might as well do it with xml like everyone else is doing, so
> remove all my registry config saving stuff and replace it with a simple
> class that uses an in-memory only dataset and table tries to read the xml
> file named "SwarmIni.xml" and if it doesn't exist, create one by building
> the config schema on the in-memory table, and then populating a row or
> rows with my config data and create the file. WriteXml over-writes the xml
> file, so I didn't have to worry about deleting the file.
>
> It worked fine as long as I named the file swarm.exe, the file and the
> config screen would track. However, when I renamed the exe to .scr all
> kinds of strange things would happen. First, I would watch it create the
> xml values, I would bring up config and change a value, shut down the
> screensaver, reload it and see that the new values were there, and then
> I'd get curious and open up the xml with notepad and find the OLD values
> there!! Notice I say that it worked normally as long as it ended in exe
> but seemed to be working with some sort of ghost-xml file with new values
> AND create a visible xml file that did not track with my config changes.
> It was not a case of different names, the file name was a constant, in
> only ONE place in the program.
>
> It was as if windows was kidnapping the xml file!! Despite doing a search
> telling it to include system32 and all system subdirectories, it would
> find any file except xml files, even non-xml files in system32 but it
> would not find that file I was seeing right there in front of my face! Now
> ain't this strange??
>
> I solved it! I simply included the application path so that the config.xls
> file created was SwarmIni.scr.config.xls and then no matter how I named
> the extention, the data in the config screen, and that in the xml file
> would track.
>
> So, while I never ever did find out what was happening, I did cure it by
> specifying the path. I suspect that windows is kidnapping a copy of the
> xml file and redirecting things some how. I still can't get search to find
> my xml files tho. I have show hidden and show system files turned on.
>
> I learned three important rules of xml programming ....
>
> 1. Always specify a path, never just give it a name and trust it to create
> a file in the location you expect, without this bizarre non-tracking
> behavior cropping up.
>
> 2. Never, ever copy your write method to the read method and change the
> name of the method and the code to do the reading. What I did by accident,
> was that I had the read method, callling the write method IF the file did
> not exist, which was fine and dandy, but in the branch I executed when the
> file already existed, I had a read early on and a spurious
> DataTable.WriteXml call, but writing an xml file while my xml helper class
> was supposed to be reading, and hadn't disposed of the table doing the
> reading yet, caused some strange feedback loop to start. My program would
> appear to execute, but some process would end up looping, and my hard
> drive light would start thrashing like crazy. There was no visible
> process, and the every time I ran my saver, everything looked ok, but my
> computer would flash, lag, the hard drive would do more and more
> thrashing, creating nothing that I could see and all kinds of strange
> things would happen which are too many to list ...
>
> 3. It is unfortunate that xml is so similar to xls - excel's spread***
> extention. I have to be extremely careful not to accidentally name
> something as xls instead of xml. In C++ I would have created a global
> #define in one place and forget about it, but in C# there isn't such a
> thing as a global constant visible throughout all the projects in a
> solution, so be careful out there!
>
> 4. I am a bit wary about this saving config info in xml format tho. Sure,
> it's portable, and its nice to read it and locate values, but it's also
> portable to malware that might be able to read those value and change
> them, and perhaps cause some sort of havoc by trying buffer over-runs and
> other stuff. In other words, I worry about this, that it might create a
> security hole here. An ini file I write, could have been in any format,
> and could have anything in it in any order, but an xml file, is
> predicable, and standard, and makes it an easy pickins target. Don't get
> me wrong, I don't dislike xml format. It's great for moving data and
> sharing it, but I wonder if it's such a great place to store config info.
> I think more security needs to be put into place. Perhaps xml with
> encrypted contents?
>
> RambleMode = Off.
>
> --
> To reply to this message take off the .NoJunkSpam off of the end of
> garryfre@xxxxxxxxxxxxxxxxxxxxxx
>


.

Quantcast