Community
Participate
Working Groups
Build Identifier: Eclipse Helios ("SR 0") When org.eclipse.equinox.internal.p2.repository.CacheManager.updateCache downloads a file, it implicitly sets the lastModified timestamp of the cache file to the current time. This is incorrect: the download is a normal copy operation and therefore the local file that is being written should have the same lastModified timestamp as the server file. As a consequence of this bug, a stale file may be kept in the cache. Reproducible: Always Steps to Reproduce: Be A, B, C times, with A < B < C 1. At time C, download a file with the CacheManager.createCache that has last been modified at time A (e.g. a file content.xml by loading a repository with a MetadataRepositoryManager); the local file is marked with last modified timestamp C. 2. Then replace the server file with a newer file that was last modified at time B. The file is newer that the cached file. 3. Next, request the same file with CacheManager.createCache; the method does not download the newer file (modified at time B) but returns the older, stale file (modified at time A).
This bug has a high priority for me because updates can be lost due to time zone differences. E.g suppose that we have a server in time zone GMT and a client in time zone GMT +4. On the server is an update available and the client performs a normal P2 update. In this case the cache on the client can be up to 4 hours older than server's content due to the time difference. This means all new updates on the server within the next 4 hours will have no effect for this client. Due to this bug downgrades are not possible without touching the modification timestamp of your old repository. IMHO it should be enough to set the modification timestamp of a downloaded cache file in CacheManager.createCache to correspond to server's modification timestamp for this resource. Also the check whether something changed or not shouldn't be "lastModifiedRemote > lastModified" instead "lastModifiedRemote != lastModified" to support downgrades. I will provide a patch.
Created attachment 183976 [details] Fix v01 Fix for two issues 1. Local cache file that is being written should have the same lastModified timestamp as the server's file. Avoids time zone problems 2. Downgrades are not possible without touching the modification timestamp of your old repository. (See stale check "lastModifiedRemote > lastModified")
Could you please provide a test case for this. Thx.
*** Bug 343513 has been marked as a duplicate of this bug. ***
Tobias, Beyhan, could you please provide a test case? Assigning to Jeff since the patch got provided by EclipseSource :)
Comment on attachment 183976 [details] Fix v01 I've released this patch.
I would still appreciate a patch. Thx.
I meant I would still appreciate a test case :)
(In reply to comment #8) > I meant I would still appreciate a test case :) Thank you Pascal for releasing this patch. I'll provide some tests. Are there any CacheManager tests?
There is no explicit test for this. It is probably simpler to just create a new test class for this validating the behaviour you've changed. Thx in advance.
Forgot to mention, in other contexts I have tested something like that simply by manually changing the timestamp on the file on disk.
Move all 3.8 bugs to Juno.
Created attachment 205360 [details] Test case for this bug It seems that this patch has been contributed to 3.7. Here are also the test cases which i promised. Therefore, this bug can be closed
why is this bug still ASSIGNED, when the patch is already part of the Indigo release?
The code has been released a while back. I finally released the test.
