I have a console application that will make modifications to 1200 systems remotely using SCCM. One of the items to be modified is a GUI menu app that is XML driven to display buttons that launch other applications. I need to change the XML.

Changing the XML wouldn't be terribly hard, but overwriting the file would be a snap. I'd just have to include the XML with my console app. The permissions should be the same either way. Is there a preferred or recommended way or is it just dealer's choice?

Edit: The target file is an app.config file that is 10KB in size. The app.config should be consistent across all target workstations. I have access to the original app.config file. I can pre-update the file and send a copy along with my updater app.


What are the expected sizes of the files you are going to be dealing with? In place updates are more complex, and without a significant reason to do otherwise replacement is the way to go. It is easier to understand and code and as an added benefit, if you have to worry about an interrupted write, it is easier to make it fail safe (in that the worst that happens is you loose the new file).

  • The XML file is a .NET app.config file that is 10KB in size. – Darkwater23 Oct 4 '15 at 4:43
  • @Darkwater23 Most file systems and physical disks use block sizes of at least 4 KB, often larger. Writing only parts of a 10 KB file won't yield much benefit. – Jordan Rieger Oct 4 '15 at 17:41
  • @Darkwater23 why aren't you just using the built in ConfigurationManager then? – RubberDuck Oct 4 '15 at 20:04
  • @RubberDuck That didn't occur to me. I usually use the Settings file to read from my own app.config. I didn't consider using ConfigurationManager to read another's app's config file. Good idea! – Darkwater23 Oct 5 '15 at 3:04

You've had several interesting answers, but for what you're discussing - the distribution of a critical configuration file to over a thousand machines - you should be following an atomic replacement protocol instead. The point is to make it impossible for the application to ever see a partially-complete configuration file, or for the update process to deliver a partial file.

  1. Create new a temporary file on the same drive where the existing file is.
  2. Open the new file, write the new configuration into it, and close it.
  3. Atomically replace the old file with the new file.

How you do #3 depends on the environment you're using. For example, In .NET, that would be the System.IO.File.Replace() method.


How would you reliably update an XML file, or any other document, without overwriting at least a portion of it? Maybe I misunderstand the question, but suppose you have the following file:


And you want to overwrite the value Foo with Foo2. How are you going to do that? You'd have to compute the new size of the file, reallocate the file size, move everything after "Foo" up by one character, and then write the new character 2 in the hole. Now imagine doing that with several different updates in the file, some that are smaller than the original content, and some that are larger. It becomes a non-trivial task. For this reason, I believe almost every app that writes files to disk works by replacing the original file with the edited copy from memory. The app lets the OS/file system worry about reallocating the space.

And performance-wise, most workloads won't be improved by trying to overwrite pieces of the original file because at the disk level, I/O happens in blocks.

Not the answer you're looking for? Browse other questions tagged or ask your own question.