Modifying an XML file but saving a copy first. Unexpected results
 

I've worked with Linux in the past, but mostly Windows. Perhaps someone can explain what I am seeing. This isn't a Linux OS, but Tomcat running under Windows. I'm thinking Linux rules apply here, but if this is the wrong forum, I apologize in advance.

I've got an app that runs under Tomcat. I needed to modify an XML config file to change a variable. The path was \app\tomcat\webapps\asset-manager-web\WEB-INF\am\conf\settings. The file was configParams.xml.

To protect myself from messing things up, I first made a copy of configParams.xml and named it configParams-ORIG.xml. I left this in the same folder as the file I was going to edit. I made the required edits and restarted the application service. The app never recognized the changes. Finally, I moved the configParams-ORIG.xml file to another folder, restarted, and everything worked.

Can someone explain why this is? I do this in Windows all the time. Why does having that original file, renamed, in the same folder cause a problem?

It may be that the application processes ALL files with .xml extension in the settings directory. Some things do look at naming convention to determine what to do with files.

What happens if you rename it configParams-xml.v01?

An example of Linux file that would be hosed by a copy with similar name in same directory would be the ifcfg-<interface> files used for setting up network interfaces. Usually when renaming files I like to append the date to the original so if my original was ifcfg-eth0 I might make a copy called ifcfg-eth0.20150508 (to show I'd copied it on May 8th, 2015). However when networking restarts on Linux it would try to process both the modified ifcfg-eth0 AND the ifcfg-eth0.20150508 because it looks for the "ifcfg-". The simple work around for that particular issue is to prepend the name so it becomes 20150508.ifcfg-eth0. Networking on restart ignores it because it starts with the 20150508 instead of the ifcfg-. In general that isn't necessary for most things in Linux but I list it as at least one example where it would be.

Since .xml is a "standard" way of creating files used by various programs it makes sense to me having that extension might cause issues so putting a different extension on it might be a successful work around.

Of course it is always possible your application is just processing everything in the "settings" directory regardless of name. Failing all else of course one can move things to different folders as you did.

Note that in Linux (UNIX) the dot is just another character in the name. It doesn't really use "extensions" the way Windows does (for most things) so it would be possible to name a file configParams.xml.ORIG in Linux. On Windows you can actually give files names like that on occasion but some things get confused because of the old 3 letter extension standard so it is best not to do it.

MensaWater,

That makes total sense. Thanks for the outstanding explanation. I might have to hang around here...

zeebish