Test and repair ARBDB Undo

[epruesse]

See also #481.

• Implement Unit-Tests
• Repair undo delete entry

Related to #86 + #480

[westram]

Example impacts of broken "undo delete":

• undo "destroy group"
• undo "move node info"

[epruesse]

Issue seems to occur only in the presence of registered callbacks.

[epruesse]

Should this really wait until 6.1? The causes the to become "corrupted". GB_read_pntr() never returns NULL as far as I can see, but it does after the undo/redo with callbacks.

[westram]

No. But not necessarily rc1.

[epruesse]

Undoing a GB_create triggers a GB_CB_SON_CREATED on the parent. Is this "expected" behavior? It sounds like a …

[epruesse]

It should trigger GB_CB_DELETED, I think, which it doesn't…

[westram]

Undoing a GB_create triggers a GB_CB_SON_CREATED on the parent. Is this "expected" behavior? It sounds like a … It should trigger GB_CB_DELETED, I think, which it doesn't…

Yes right, detected i guess

Wanted would be:

Action	Action-CBs	Undo-CBs
create	GB_CB_SON_CREATED	GB_CB_DELETE
delete	GB_CB_DELETE	GB_CB_SON_CREATED
change	GB_CB_CHANGED	GB_CB_CHANGED

[epruesse]

How about making the description match what the code is doing instead?

Like so:

GB_CB_DELETE

Triggered if the GBDATA* was destroyed.

GB_CB_CHANGE

Triggered if the GBDATA* contents where modified. In the case of GBCONTAINER this means a child was added or removed.

GB_CB_SON_CREATE

Removed. Add/remove operations on a container trigger CHANGED.

As far as I can see, that's what's happening anyway. We'd just remove the SON_CREATED. Since it is called on both add and remove, and since the CHANGE CB is also called always, the client code can stay the same.

Since it servces about the same purpose and has already seen some iterations, I've had a brief look at the inotify kernel API. Since the doesn't support rename or move operations and access isn't really useful to observe, the only worthwhile additions would be "changed_flags" and "recursive".

[epruesse]

The GB_CB_SON_CREATED issue seems to be more recent. Older versions behave as expected. The malformed GBENTRY after undoing GB_delete while having a CB registered occurs as far back as I've been able to test.

[westram]

Replying to epruesse:

The GB_CB_SON_CREATED issue seems to be more recent.

Please document with a small test (using some TEST_…_BROKEN). And how about a branch for this ticket?

Older versions behave as expected.

Do you have a revision number where it works?

The malformed GBENTRY after undoing GB_delete while having a CB registered occurs as far back as I've been able to test.

Yes, I also think this has been present for ages.

[epruesse]

added a unit test showing the broken behavior in r12391

[westram]

Ticket retargeted after milestone deleted

[westram]

Milestone renamed