Virtualization appears to be touching files

Environment: Interwoven TeamSite 6.5.0 Service Pack 1 on Win 2K Server, WebSphere 5.1 application server.

I'm using WebSphere to virtualize a J2EE web application (Java & JSPs) that has many of the JSPs stored and managed in TeamSite. The virtualization and previewing is generally working, but users have noticed that when a file is previewed its "Modified By" attribute changes and it is displayed with the Edited icon in ContentCenter.

For example, there's a file in one of the directories that displays as

foo.jsp grantk 7/26/06 3:11:44 PM

After I preview this file by clicking on its name, close the preview window and refresh the view, it displays as

foo.jsp IW_TSV 7/26/06 3:11:44 PM

with an icon indicating that it has been edited, yet the modification date hasn't changed. Digging a bit deeper into the properties for that file shows no changes, and comparing it to staging reveals that the supposedly modified version in the workarea is identical to the version in staging.

This is playing merry havoc with users' ability to use the "View > My Modified Files" or "View > Modified Files" menu items to locate files they need to submit after an editing session. Files they edited have had the username changed so they don't display when using "My Modified Files", but if they use "Modified Files" they end up with a long list of files in the workarea that anyone has previewed.

The IW_TSV user is the account used to make the TeamSite IFS drive available on the application server. The most puzzling aspect of this (to me anyway) seems to be that the IFS filesystem is mounted read-only on the app server (since it shouldn't be modifying files) - under these circumstances the file shouldn't be modified when it is read by the application server, yet it is.

Has anyone seen this behaviour before? Have any tips/workarounds? Is this a glitch in IFS access to TeamSite content?

Find more posts tagged with

Comments

Adam Stoller

Is foo.jsp a generated file or a static file?
When you compare the file against staging - are you checking all the different types of compares - like metadata compare?

koryn

foo.jsp is a generated file.

I checked the metadata - the section containing the differences is below:

Before previewing:
[indent]

Location: //WLG-CM1/default/main/Internetv2/EDITION/#166/contentiw/pages/forhome

Modified By: company\grantk
Modified: 7/26/06 3:11:42 PM

Version: 2
Comment: Regenerated entire site.

[/indent]

After previewing:
[indent]

Location: //WLG-CM1/default/main/Internetv2/WORKAREA/main/contentiw/pages/forhome

Modified By: COMPANY\IW_TSV
Modified: 7/26/06 3:11:42 PM

Version: 2+
Comment:

[/indent]

Given that TeamSite thinks something about the file has changed, I can understand the difference in Location, Version and Comment.

I still don't understand why the Modified By field has changed (or how it could happen) - that's the only difference before and after previewing.

Adam Stoller

foo.jsp is a generated file.

I checked the metadata - the section containing the differences is below:

Before previewing:
[indent]

Location: //WLG-CM1/default/main/Internetv2/EDITION/#166/contentiw/pages/forhome

Modified By: company\grantk
Modified: 7/26/06 3:11:42 PM

Version: 2
Comment: Regenerated entire site.
[/indent]

After previewing:
[indent]

Location: //WLG-CM1/default/main/Internetv2/WORKAREA/main/contentiw/pages/forhome

Modified By: COMPANY\IW_TSV
Modified: 7/26/06 3:11:42 PM

Version: 2+
Comment:
[/indent]

Given that TeamSite thinks something about the file has changed, I can understand the difference in Location, Version and Comment.

I still don't understand why the Modified By field has changed (or how it could happen) - that's the only difference before and after previewing.

Anytime you click Preview you are, in fact, re-generating the file. I'm pretty sure iwregen invokes iwpt_compile.ipl with the '-smartwrite' flag so that if the resulting output is unchanged from the existing, nothing is changed. I'm not sure if iwgen does the same thing or not - and I'm not sure whether clicking on Preview does the same thing or not (I'm talking about OOTB - if your Preview links have been customized to call your own scripts - that's completely in your area to fix).

A relatively simple test should be able to tell you what does what.
Select a non-modified generated JSP file - and then (I believe) Actions > Regenerate - and see if the generated file changes.

Try the same thing with Actions > Generate (I think you can do that from the generated file - if not you'll have to select the DCR first)

Try the same thing by bringing up the DCR in read-only mode - I believe Preview is still enabled - so click it and see what happens.

Lastly - bring up the DCR in edit-mode and click Preview.

Note all the results.
If you're positive that the PT does not do anything programmatically to touch the EAs or metadata on the file itself - the issue would be that Preview (and perhaps Generate) does not use the '-smartwrite' option and that is causing the file to actually become modified.

The change in ownership is most likely a Windows thing - where there is no seteuid functionality - although why it would set it to IW_TSV instead of SYSTEM is certainly peculiar.

In any case, I suggest you collect the above information (and anything else you can think of) and open a Support case with it. Let us know what happens.

koryn

Hi fish,

Thanks for the reply - here are the results:

Action > Regenerate Page No change to the generated file.

Action > Generate Page (Need to select the DCR for this) No change to the generated file (apart from being locked afterwards, not surprising).

Preview Generates temporary version of page (zz_tst_grantk...), so no change to the generated file.

Note that when the file has changed it's been when I've previewed it by clicking on its name in the CC Smiley Tongue

ro file list view.

I've just noticed something interesting after trying to reduce some of the clutter in the "Modified Files" view. I've been carefully (!) overwriting some of the touched files with the version from staging to restore the original Modified By field. After I've done this, if I preview the file by clicking on its name the Modified By field no longer changes.

It's as if there is some hidden state being changed on the first preview that remains that way when the file is overwritten from staging.

Here's my hypothesis: the IW_TSV user is a reasonably new addition to this server; we had the branch set up and operational before adding virtualization. I think what is happening is that TeamSite is erroneously considering the file to be 'modified' because of this new user, and a side-effect of this is the change to the "Modified By" field.

I've tried duplicating the effect that previewing the file has by going through the IFS drive directly, but can't reproduce it. There must be a filesystem operation that occurs when the application server reads the file (I believe this is a SAMBA mount of the IFS drive) that doesn't occur when Windows file-sharing reads the file. If I had access to a Linux or Mac OS X box I could test this further, but alas, I don't.

Anyway, one workaround now is simply to preview the files then overwrite them from staging. Very time-consuming, but on the bright side it's a one-off.

(I already have a support case open, but they claim the problem lies with the application server we are using and not TeamSite. I'll send them the results of this investigation and see if they change their tune.)

Cheers,
Koryn

Adam Stoller

Hmm - very strange indeed.
Well, hopefully all the investigation work will pay off.

Good luck

koryn

Another piece of information: the virtualization is configured to inject the in-context editing toolbar. I turned that off to see if the file modification still occurred, and it does.

nipper

Another piece of information: the virtualization is configured to inject the in-context editing toolbar. I turned that off to see if the file modification still occurred, and it does.

The injection of the SCE is in memory and never saved to disk.

koryn

The injection of the SCE is in memory and never saved to disk.

I wouldn't expect it to be saved to disk, but given that the whole situation is inexplicable any additional information could potentially be useful.

Cheers,
Koryn

koryn

Anyway, one workaround now is simply to preview the files then overwrite them from staging. Very time-consuming, but on the bright side it's a one-off.

Unfortunately it turns out that this isn't a permanent fix. After the file has been edited and submitted, the problem returns.

In all its detail:

Click on a filename in CCPro; a new window opens with the file correctly virtualized.
Refresh the CCPro view. The Modified By field for the file now shows "IW_TSV", and the file's icon indicates it has been modified.
Revert the file to the (identical) version in Staging.
Click on the filename again; a new window opens with the file correctly virtualized.
Refresh the CCPro view. This time the Modified By field retains the correct userid.
Edit the file's DCR, save the changes and generate the output file by using the Generate button in the editing form.
Submit the file. The Modified By field shows "IW_TSV", because of the automatic preview when the file was generated, and the file's icon indicates it has been modified.
Edit the file's DCR, save the changes and this time generate the output file by using the "Actions > Regenerate Page" menu item (to avoid the preview).
Submit the file. The Modified By field shows the correct userid.
Click on the filename; a new window opens with the file correctly virtualized.
Refresh the CCPro view. The Modified By field for the file now shows "IW_TSV", and the file's icon indicates it has been modified.

So once the file has been edited and submitted, even if the Form's Generate button isn't used in order to get the correct userid against the change (which is a great nuisance), we're back in the original situation.