5.5.2 store in 6.5 : deleted files are back !

Hi folks,

my last day at work, before end-of-year holidays... Busy preparing 5.5.2 upgrade to 6.5 sp2. Hit a snag

We copied a production backing store of 5.5.2 (the IWSTORE/default folder) to 6.5 SP2 Patch62533 system. Solaris 9.

What I seem to be having, is that ALL the files that were ever created (submitted or not), and then deleted or renamed on the 5.5.2 system, are showing in the 6.5 user interface (testing with CCPro) under View : All Files.

These are all tagged (icon image with ALT text) "marked for delete" or "marked for move/rename". Most have version 0+, but also found sound 1+ (probably I could find other N+ versions).

Most of these are NOT listed in the View : Modified Files, while some are. So far, it would seem that 0+ version files are not listed, and others (found 2 deleted files at version 1+) are listed.

No changes have been made to files in the 6.5 system, so this is all fresh how it was imported.

Import was done by simply copying the IWSTORE/default of 5.5 into the 6.5 IWSTORE folder, and activating the default store (iwstoreadm -a default). The original 6.5 default store had been de-activated and renamed to test65 before doing that.

What's going on? is this normal? Documented? Or a bug on our side? Bad procedure for migrating backing store?

cheers & happy holidays
Frederik.

Find more posts tagged with

Comments

Frederik

I'm surprised still noone has reported seeing this...

Anyway, we've done several days of testing on this, and have been able to break this down to simple scenarios.

btw, Support so far said : "There cannot be a file marked for deletion with version 0+ ". Unfortunately, we're seeing just such files.

(this is a quick re-edit of a post to Support, pls forgive the elaborate language).

Remember, our situation is a 5.5.2 SP4 (on Solaris 8) migrate to a fresh 6.5 sp2 Patch62533 (on Solaris 9). (etc, see 1st message)

CASE 1

(all actions via shell: UNIX commands and TeamSite CLT)

PRECONDITIONS on TS 5.5 :
a new store teststore,
with a new branch main/testbranch (empty, based on INITIAL),
with workareas wa01 and wa02, both empty, based on INITIAL.

-> in wa01
file "cr-ea" created : echo "cr-ea" > cr-ea
set extended attributes to file (same EA as if this file was generated out of a DCR)

file "cr-ea-del" created : echo "cr-ea-del" > cr-ea-del
set extended attributes to file (same EA as if this file was generated out of a DCR)
delete : rm cr-ea-del

Do GetLatest with overwrite, using CLT:
iw-home/bin/iwupdate -w -r $BR_VPATH/STAGING $WA_VPATH

At this point, both files have disappeared from wa01 (one from the iwupdate, the other because of Unix delete)

Deactive store, and copy/activate on TS 6.5, and both files are listed in the "All Files" view, with Marked for deletion and Version 0+. (They do NOT show up in "Modified Files" view.)

Clearly this is against the design !?

Note : a similar scenario WITHOUT Extended Attributes yields "normal" results.

CASE 2

SAME PRECONDITIONS on TS 5.5 :
a new store teststore,
with a new branch main/testbranch (empty, based on INITIAL),
with workareas wa01 and wa02, both empty, based on INITIAL.

-> in wa01
file "cr-subm-del" created : echo "cr-subm-del" > cr-subm-del

Submit this file : iw-home/bin/iwsubmit ...
Delete this file : rm cr-subm-del

-> in wa02 (still empty)
Submit wa02 with overwrite :
iw-home/bin/iwsubmit -w -r /teststore/main/testbranch/WORKAREA/wa02

This reports "force deleted" on the file cr-subm-del

-> back in wa01
Do GetLatest with overwrite, using CLT:
iw-home/bin/iwupdate -w -r $BR_VPATH/STAGING $WA_VPATH

At this point, the file has disappeared from wa01

Deactive store, and copy/activate on TS 6.5, and the file is listed in the "All Files" view, with Marked for deletion and Version 1+. It ALSO shows up in "Modified Files" view.

Clearly this is against the design !?

Note : a similar scenario on a file WITH Extended Attributes yields the same buggy results.

These 2 cases may seem not to be functionally logical, but they do represent some real world issues we're seeing when copying our Backing store from TS 5.5 to TS 6.5.

--
greets, Fred.

jbonifaci

I didn't quite follow what you were doing, as I didn't read it all, but I'm guessing what you're seeing is working as designed.

As we all know, unless a file has never been submitted to staging, it is never really gone until you remove every reference to it in staging and every edition.

That being said, in 5.5, when you "deleted" a file in a workarea, it is still there and can be seen by viewing modified files. Once the deleted files are submitted to staging, you can then no longer see them in a workarea.

In 6.x, however, deleted files are seen as "Marked for deletion" until you actually submit them to staging. Then, even after you submit it to staging, you can then still see them in the workarea as "Deleted" if you "View: All and Deleted Files".

If this is what you are experiencing, then it is working as designed. If you are experiencing something else, then I would continue to work with support.

~Jeff

Frederik

Jeff,

thanks for your input, but I do believe we're facing a real issue here, not just the new approach of TS 6.5 on deleted files.

I can't make it really easy, because you need a number of actions to reproduce it.

One of the easiest reproductions: on TS 5.5, new store & branch
WA1 : new workarea, empty
WA2 : new workarea, empty
WA1 : new file X with extended attributes
WA2 : submit with overwrite
WA1 : get latest with overwrite

move this store to TS 6.5, and file X will show up on the "All Files" view of WA1, in grayed-out style, icon "Marked for deletion" and Version 0+.

Our opinion is that this is not logical, since the file was REALLY supposed to be gone as a result of getlatest-overwrite.

EDIT :
mmm, that scenario above is a bit too long even. I was simplifying it on the fly from a longer scenario, but you can just do

One of the easiest reproductions: on TS 5.5, new store & branch
WA1 : new workarea, empty
WA1 : new file X with extended attributes
WA1 : get latest with overwrite

Edited by Frederik on 01/13/06 02:56 AM (server time).

Frederik

For those interested, I will attach a script that reproduces a large number of scenarios with 2 workareas and files being created, deleted, submitted, etc, combined with submit-overwrite and getlatest-overwrite.

There are 2 cases where I see bugs (non-logical behaviour), see my second post.