XML file timestamps issue in v8

[Tim Frost]

I have a topic which rarely changes, except that it contains a variable reference which contains a version number. So in the build process I 'touch' the XML file with the current date and time before publishing; and I have the option to sync timestamps set in the skin (and in the project). For a long time this has worked well to (a) force the HTML and JS to be regenerated, and (b) make it clear, when uploading using Beyond Compare, that this file is later than the last upload to the server and needs to be included in the upload.

I have now discovered that the 'touch' no longer works in v8 because the timestanp is held inside the XML file; and that although the file timestamp is ignored for the XML file, it seems to be used on the HTML/JS, because these were not regenerated for this topic in my last build. Their time matched the internal XML time because of the sync option. I cannot be certain of that fact, because I have already changed the build step to replace the 'touch' with deletion of the HTML/JS files for this topic immediately before publishing.

I mention it here in case this v8 'improvement' catches out anyone else who has used 'touch' in the past.

[Alexander Halser]

Hi Tim,

This has indeed changed. The reason for the dedicated "modified" attribute in the <topic> tag is that version control systems such as SubVersion (SVN) simply don't care about the file timestamp. Synchronizing content via SVN set the timestamp of the topic to the last sync date/time, not the date when it was edited.

The problem really became obvious with the new link lists, but actually affects other functions such syncronization of translation siblings as well.

The easiest solution for you would be to remove the modified attribute from that file. You said it changes rarely. Open the XML file with a text editor and remove the modified attribute completely. This will trigger the fallback to use the file timestamp, like before. Just make sure that you don't overlook a possible modification of this topic in Help+Manual. If you edit the topic in H&M, it will put the modified attribute back it.

[Tim Frost]

Oops. Your suggested solution lasted only a month and a bit, until I made a change to the file and forgot to remove the 'modified' attribute. So I have written a little program to do this which I can insert into the build process before publishing the help. So this attribute will always be missing when I publish, and at the same time the rewritten file has been 'touched' to ensure that the output files have the same timestamp.

It might be good to have a topic option to disable this v8 'improvement'; is there no-one else who has a few topics which mainly change only because included variables have new values?