why is DCR deleted when save fails

when saving a DCR the following error appears and the DCR is deleted from the current workarea. why is the DCR being deleted?

"The DCR [full vpath to DCR] failed to save. Check the path or contact your Teamsite administrator."

At first i thought this might be a permissions issue, but the files in question appear to have the correct permissions -- they belong to the correct group and are group read and writable.

BTW, we are running TS 5.0.2 under Solaris 8.

Find more posts tagged with

Comments

tvaughan

I don't understand . . .. does it save correctly and then gets deleted on subsequent edit/save attempts?

Because it sounds like you never successfully save it in the first place.

If you already have a DCR and some user can't successfully make edits to it, check to see if that user not only has write permissions on the DCR and the data directory, but also if that user has write permissions to the WORKAREA.

Tom

robverhoeven

We at Philips Lighting had the same problem, for which no patch will be available. In some cases the data was saved, in most cases the data wasn't saved. The only solution we could start was upgrade to 552. (unfortunately) Nevertheless, we don't have these saving problems any more with 552.

james1

> when saving a DCR the following error appears and the DCR is
> deleted from the current workarea. why is the DCR being deleted?

In TST5.0, at save time, TST first deletes the DCR, then writes the DCR over the deleted file. I don't remember why it is deleted first -- there was some problem being worked around.

Apparently, the delete succeeds for you, but the write fails. I don't know why the write is failing for you.

I don't know if this (delete, then write) is still the behavior for TST5.5.2, but as another post said, upgrading to 5.5.2 seems to elimindate the problem.

Hope this helps.
-- James

--
James H Koh
Interwoven Engineering

Migrateduser

I believe that the reason why dcr's were deleted and then recreated in TS5.0.x was due to a lack of a working Truncate method openapi's file IO classes (you could overwrite an existing file, but the size of the file would not be shortened to the end of file character).

I think that this was fixed in TS5.5.x with the setNumContentBytes method in the IWSimpleFile class.

The problem with the dcr being deleted when trying to save I believe is also a known issue that was fixed in a service pack for TS5.0.1 or TS5.0.2. I think it had to do with the order of checking to see if a file was writable.

mick

do you have any more info on the known issue and which service pack may have fixed it? as far as i know, both SPs were installed for our implementation.

also, i've tried to search the support site for any info on this issue and haven't been able to find anything.

mick :-)

Migrateduser

Well the bug reference for the dcr being zero'ed out was 20644 (which should be in the patch notes or release notes for the service pack). Looking back again it looks like it was not fixed until TS5.0.2 and above.

Please see:

[url=http://support.interwoven.com/library/manuals/templating/html/tst.502.rn/css/tst.502.rn_10.htm[url]
[url]http://support.interwoven.com/library/manuals/templating/html/tst.552.fxbg.html]http://support.interwoven.com/library/manuals/templating/html/tst.502.rn/css/tst.502.rn_10.htm>http://support.interwoven.com/library/manuals/templating/html/tst.552.fxbg.html>[url]http://support.interwoven.com/library/manuals/templating/html/tst.552.fxbg.html]http://support.interwoven.com/library/manuals/templating/html/tst.502.rn/css/tst.502.rn_10.htm[url]
[url]http://support.interwoven.com/library/manuals/templating/html/tst.552.fxbg.html

I would highly recommend an upgrade to TS5.5.2 over TS5.0.2 if you are going to go through the trouble of upgrading.

You also might have luck if you make sure that the if you are editing a dcr as part of a workflow that you not use lock=t for the task and make sure the file is unlocked before any user is asked to edit the file (as the problem seems to show up only when an author is not supposed to be able to edit a file, specifically when it is locked by someone else).

I just noticed however that you say you are seeing this issue still in TS5.0.2 (are you sure that this is the correct version you have)? The underlying problem of the limitation in the openapi library is still present in TS5.0.2, but I know for sure that this was fixed in TS5.5.2 (as it comes with a new version of OpenAPI that has the method I mentioned earlier).

Edited by nacks on 01/08/03 06:01 PM (server time).