Bug 559264 - Same modification stamps for different states of a resource
Summary: Same modification stamps for different states of a resource
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 4.14   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Resources-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-16 10:47 EST by Vladimir Piskarev CLA
Modified: 2020-01-16 12:45 EST (History)
1 user (show)

See Also:


Attachments
A project with a failing test case demonstrating the issue (3.90 KB, application/zip)
2020-01-16 10:47 EST, Vladimir Piskarev CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Piskarev CLA 2020-01-16 10:47:04 EST
Created attachment 281524 [details]
A project with a failing test case demonstrating the issue

According to the spec, "the modification stamp of two distinct resource states should be different if and only if one or more of the attributes listed in the specification as affecting the modification stamp have changed". The current resource implementation can break the contract.

Steps to reproduce:

0. Let us have a resource R in state S0.

1. Modify R so that it has a new state, S1. Remember R's modification stamp for S1.

2. Undo the modification so that R is reverted to the original state S0, with the original modification stamp.

3. Modify R in some other way so that it has a state S2 that is different from S1.

Observe that R's modification stamp for S2 is the same as R's modification stamp for S1:

      State  ModStamp
Orig   S0     A
Mod1   S1     B
Undo   S0     A
Mod2   S2     B


More information:

Bug 84350 introduced a new API, IResource#revertModificationStamp(long). But the resource implementation was not updated to keep track of a separate "next modification counter" for a resource. This opened the door to the described issue.

A similar issue existed in AbstractDocument and has been fixed in bug 109104. See https://github.com/eclipse/eclipse.platform.text/commit/77d13068054c00d1dfc27f8c47f8af7576a241e7
Comment 1 Andrey Loskutov CLA 2020-01-16 12:18:46 EST
Can you please provide a reproducer?
Comment 2 Andrey Loskutov CLA 2020-01-16 12:20:24 EST
(In reply to Andrey Loskutov from comment #1)
> Can you please provide a reproducer?

Sorry, missed the attachment. Do you want to propose a patch?
Comment 3 Vladimir Piskarev CLA 2020-01-16 12:42:41 EST
(In reply to Andrey Loskutov from comment #2)
> Do you want to propose a patch?

Hi Andrey,

I'm not ready to propose a patch at this time, sorry. I'm not pushing on it. Just thought the issue was worth reporting, so...

I should have added that modifications in steps 2 and 3 must be "affecting" ones, i.e., they must affect the modification stamp. Hopefully, this was clear from the "state chart".
Comment 4 Vladimir Piskarev CLA 2020-01-16 12:45:27 EST
(In reply to Vladimir Piskarev from comment #3)
> I should have added that modifications in steps 2 and 3 must be "affecting"
> ones, i.e., they must affect the modification stamp.

Correction: in steps *1* and 3, sorry.