Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
zz_preview files being created when previewing DCR
marczee
We recently upgraded from 4.5.1 to 5.0.1 and we are noticing problems when we try and preview DCR's in the 5.0.1 environment. There are zz_preview files that are bieng created in the workarea of the DCR and it is corrupting that branch. If anyone has experienced this or knows what is happening please let me know. Thanks.
Find more posts tagged with
Comments
sajiddc
Very weird. Would it be possible for you to paste a section of your templating.cfg? "corrupting the branch" is a very vague term. Please provide a little bit more descriptiion as to what is happening.
Last but not least, where exactly is the zz_preview files are being created. Is it getting created right under the WORKAREA\my_workarea or somewhere else? A vpath path to your zz_preview file would be helpful.
marczee
The vpath is /default/main/sales_extranet/main/WORKAREA/workarea. This is where the zz_ files are being created. The file names that are created are: zz_tst_username_0_manifest and zz_tst_username_0_preview.jsp. Once they are in this path and we go to that path in the application and hit refresh we keep getting random content displayed with N/A files and other garbage. Here is a piece of our templating.cfg:
<category name="snc_main">
<locations>
<branch vpath-regex=".*" />
</locations>
<data-type name="hotnews">
<presentation>
<template name="headlines.tpl" extension="jsp">
<locations>
<branch vpath-regex=".*" preview-dir="/">
<directory dir-regex=".*" />
</branch>
</locations>
</template>
<template name="details.tpl" extension="jsp">
<locations>
<branch vpath-regex=".*" preview-dir="/">
<directory dir-regex=".*" />
</branch>
</locations>
</template>
<template name="printableURL.tpl" extension="jsp">
<locations>
<branch vpath-regex=".*" preview-dir="/">
<directory dir-regex=".*" />
</branch>
</locations>
</template>
</presentation>
</data-type>
sajiddc
Are you able to see the zz_* files from your TS GUI (aka browser) or just from the file system interface? Also are you on windows or solaris? I think I have seen something similar before. Let me check and see.
manju166
We have the same problem.
the preview files gets created in the filesystem and not in the Teamsite GUI
it gets created under workarea
H:\main\HumanaBranch\IntranetNewsBranch\WORKAREA\DeveloperWorkarea\
Is there anyway we can stop it.
thankyou
manju
marczee
We are seeing it in the file system only. We are running on Solaris OS 5.8.
sajiddc
That is how TS 5.x was designed. You need the 2 zz* files so that you can do preview from Templating. Actually let me rephrase, everytime you try to do preview, TS Templating will create the zz* file in your workarea. If you delete them, it will come back the next time you do a preview from TS Templating.
And the TS GUI (aka browser) does not display the zz* filename since the general assumption is that most ppl will be working from the TS GUI.
Now I have not tried this but you are certainly welcome to try the following:
1.)Apply the +h attribute on the 2 zz file.
2.)And then configure your Windows Explorer so that it does not show/display hidden files.
I am not sure if the above will work or not. If you try it, please do post your comment/results so that others can benefit as well.
Hope that helps.
sajiddc
Please see my post in response to manju16. That should explain you why the 2 zz* files are created.
marczee
That doesnt explain why that corrupts the workarea. Once those files are in the workarea no one can view the correct content in that workarea. Everytime a user refreshes the workarea they see garbage content or incorrect content
sajiddc
Finally.. I understand your problem clearly. I guess I am not the brightest bulb, eh. j/k
Which service pack are you using on your TS box? I will wait for your reply. In the meantime, I will go through my notes and see if I have any quick resolution or not. If not, most likely you will have to contact technical support.
marczee
I just installed TST5.0.1 SP2 on our box and there is no difference.
sajiddc
hmm... now dats scary... hahahaha.. j/k. Sorry I am in one of those goofy moods right now.
Now coming back to our problem. How about listing some of the files (partial listing of your WORKAREA) in here after it messes up. I am very sure that I have once heard something similar. Let me see what I can find out for you. Though no promises.
Also, did you try clicking on any of the junk files? How about opening them? What do these file contain? Anything else like proxy remapping that could be a possible culprit.
I am hoping that other devnet memebers will also jump in and help us.
sajiddc
One last thing. Have you checked the logs. Any anomalies??
marczee
Nothing in the logs out of the ordinary. When the user refreshes their browser they cannot view the content in the workarea.
sajiddc
And I suppose things return to normal when you delete those 2 culprits (meaning the zz* files)
iwovGraduate
Can you please elaborate on how the zz files corrupt the workarea ? As far as I know (will be happy to be proved wrong) these files are harmless. When you say "no one can view the correct content in that workarea", it really doesn't help much. Please specify what do you expect to see and what you see in the workarea (from windows explorer ?).
Do you see the same problem if you try to view from a unix terminal/shell ?
Also, since your TS is on Solaris and your are trying to see the files with Windows explorer, you are using Samba to mount IFS drive ? Would help if you specify all the details.
Edited by iwovGraduate on 08/22/02 02:12 PM (server time).
marczee
When we delete these files it returns to normal. I have attached a screen shot of what the users see when the zz* files are in the workarea.
Migrateduser
Just a thought, if you click on the gui frame that is supposed to display the file listing of the workarea and then do a view source does the file have well formatted html?
The image you posted looks like there is something wrong in the html that is causing the table to be broken.