Hi Jens, Jens Geile wrote: >> If you really need to get the absolutely latest version of the local wpkg.xml I recommend putting a batch file onto the server and have WPKG client running that batch file instead of wpkg.js directly. >> This allows to launch wpkg.js and then copy wpkg.xml with the batch script. > Uh, why not just use config.xml to configure the location of the logfiles and wpkg.xml files? > > <param name='settings_file_path' value='\\\\iserv\\install\\wpkg\\status' /> Huh, wouldn't that mean that all clients write to \\iserv\install\wpkg\status? In fact overwriting each other. Especially this is bad due to the fact that the first client upgrading updates the "local" settings file with the new package node. The second client will not run the upgrade commands (but probably detect that the package is not installed and re-install it). In any case it's a bad idea that all clients write to the same file. This brings up the idea in my mind to allow "[HOSTNAME]" within the settings_file_name and probably also within settings_file_path - this could solve the problem and have WPKG to write the file directly to the server when using <param name='settings_file_path' value='\\\\iserv\\install\\wpkg\\status' /> and <param name='settings_file_name' value='wpkg-[HOSTNAME].xml' /> Probably an idea for WPKG 1.1 testing release > <param name='log_file_path' value='\\\\iserv\\install\\wpkg\\status' /> > <param name='logfilePattern' value='[HOSTNAME].log' /> This is unrelated to the settings file path, but brought me to the idea outlined above. br, Rainer |