during IWMIGRATE submit filter applies rules of default store

I discovered the following today, that I've never seen mentioned in devnet forums or KB/tech articles. I filed a case for it, but I thought I'd share.

Imagine you wanna use iwmigrate, to copy a branch from store SOURCE to store TARGET.

iwmigrate -o /extra/data/gwts/iw-store/TARGET -m /iwmnt/SOURCE -b /SOURCE/main

Does the submit filter apply, you wonder? Well, yes, in a weird way!

The submit filter will be applied, as though the submits are happening in the "default" store.

For instance, the following submit.cfg rule would be applied

  ^/default/main/WORKAREA/.*$ # main branch in default store
  {
     .* { gid=test perm=0664 }
  }

... while the following submit.cfg rule would NOT be applied.

  ^/TARGET/main/WORKAREA/.*$ # main branch in TARGET store
  {
     .* { gid=test perm=0664 }
  }

This is confirmed in the iwmigrate output if you have in iw.cfg the setting [iwserver] debug_event_handler=yes

-> EVENT HANDLER: gid=test performed on "/iwserver/default/main/WORKAREA/temp_workarea/upload/images/homepage/yacht.gif"

I'm surprised.

My expectation for this would actually be
- that the submit filter is not at all applied on iwmigrate, because the current filter shouldn't impact a copy operation of old data.
- if it is being applied, it should be optional through a command argument to iwmigrate.
- if it is being applied, I'd imagine it should be applied with the proper TARGET store name.

The fact that submit.cfg applies to iwmigrate is at least a documentation bug - IHMO.
The way submit.cfg applies to iwmigrate, may be an implementation bug also - I leave that up to IWOV to decide.

--Fred.

Find more posts tagged with

Comments

Adam Stoller

I discovered the following today, that I've never seen mentioned in devnet forums or KB/tech articles. I filed a case for it, but I thought I'd share.

Imagine you wanna use iwmigrate, to copy a branch from store SOURCE to store TARGET.
iwmigrate -o /extra/data/gwts/iw-store/TARGET -m /iwmnt/SOURCE -b /SOURCE/main
...

My expectation for this would actually be
- that the submit filter is not at all applied on iwmigrate, because the current filter shouldn't impact a copy operation of old data.
- if it is being applied, it should be optional through a command argument to iwmigrate.
- if it is being applied, I'd imagine it should be applied with the proper TARGET store name.

The fact that submit.cfg applies to iwmigrate is at least a documentation bug - IHMO.
The way submit.cfg applies to iwmigrate, may be an implementation bug also - I leave that up to IWOV to decide.

--Fred.

I'd expect the submit.cfg to apply because TS is replaying the events stored within / between editions - so submit operations are occurring.

The fact that it's using the source store instead of the target store (I'm assuming the source is 'default') would seem to be a bug because the file is being submitted in the target store - so I think that's worth following up with Support - though it's possible that it could be justified by (again assuming the source store is 'default') saying that in order to replicate the branch's content's metadata (not EA's - file metadata, owner, mode bits, etc.) "correctly" - the source store's information is used.

It's a questionable justification (I can see arguments on both sides) - and would lead to my suggesting that you file a FR to allow overriding of the default semantics - with the target store used and/or perhaps with no submit.cfg referenced -- though I think this would end up being a change to the submit functionality more than iwmigrate.

Frederik

Hi ghoti... thanks for your reflections Smiley Happy

I'd expect the submit.cfg to apply because TS is replaying the events stored within / between editions - so submit operations are occurring.

The reason I disagree is that iwmigrate is "marketed" as a tool to copy branches to other locations. It's not explicit that under the hood, this is done by _replaying_ submit event, rather than by copying the relevant bits (*). Plus, the target location could also be another server, that could have another submit.cfg. Or, even if on the same server, the submit.cfg could now be different then what it was when the content was created originally.

OTOH, if the target is on another server, that has other groups (gid)/user (uid), then the ability of applying submit filter (provided it's understood how it works), is certainly useful.

(*) Actually, the replaying of submit events also means that if you look at file/submit histories, all submits are timestamped at the time of the iwmigrate, instead of the original submit, which is a side-effect I strongly dislike too.

The fact that it's using the source store instead of the target store (I'm assuming the source is 'default') would seem to be a bug (...)

I tried this in a number of ways: iwmigrating "default" to "TARGET" and also "SOURCE" to "TARGET" (where "SOURCE" != "default"). Admittedly, the test with SOURCE was using a store that was originally created as default, and later renamed to "SOURCE" as such:

iwstoreadm -d default
cd `iwgetstore`
mv default SOURCE
iwstoreadm -a SOURCE

(...) file a FR to allow overriding of the default semantics (...) though I think this would end up being a change to the submit functionality more than iwmigrate.

well, first I'd need to see some documentation on what is default semantics by design vs default semantics as per implementation Smiley Wink

But since the target of iwmigrate is a non-running store, I feel like iwmigrate is sorta activating that store, like it's running a mini Teamsite server within. You can also see in the iwmigrate log that it's loading/parsing the submit.cfg (and looking for an autoprivate.cfg which we don't use/have), so I guess a flag to make it use a specific submit.cfg would be easy to add to iwmigrate. Remains the current weirdness with what vpath (storename = default !!) it's matching with.

The support case is filed, but has not gotten a response yet... "Low priority" case as there's no system down, no ton of users screaming.

--Fred