Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 19789

Summary:	Can't save because file is 'out of sync' (see problem 16280)
Product:	[Eclipse Project] Platform	Reporter:	Olaf Graf <olaf.graf>
Component:	Resources	Assignee:	Platform-Resources-Inbox <platform-resources-inbox>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	normal
Priority:	P3	CC:	neil
Version:	2.0
Target Milestone:	---
Hardware:	PC
OS:	Windows NT
Whiteboard:

Description Olaf Graf

2002-06-10 10:11:17 EDT

We have the following problem (and solution(?)):

We are using ClearCase and Samba to manage our resources.
It works fine to to open a java file, edit and save it one time(!). But
the second time eclipse returns an 'out of sync' error (this is, we have
to refresh first).

The problem seems in class

   'org.eclipse.core.internal.localstore.FileSystemResourceManager'

in method

public void write(IFile, IPath, InputStream, boolean, boolean, boolean, ...)

At the end of this method is code:

...
   getStore().write(localFile, content, append, monitor);

   // get the new last modified time and stash in the info
   lastModified = CoreFileSystemLibrary.getLastModified(...);
...

'getLastModified(...)' is to fast (!!!), it doesn't return the time the file
gets saved now but the time the file was saved earlier.

I uncommented the statement

  hasNatives = true;

in class 'CoreFileSystemLibrary', this seems to temporary fix the problem.

Regards,
Olaf Graf

Comment 1 Neil Swingler

2002-06-17 03:28:19 EDT

Do you mean you commented it out to stop Eclipse using native calls?
I renamed the core_2_0_5.dll to achieve that effect.
It made no difference. The problem still exists.

Comment 2 Olaf Graf

2002-06-17 03:46:48 EDT

Neil, you are true. But unlike yours it works with my installation (I'm using 
JDK 1.4).

It it doesn't work the only way I can see is to add a delay between saving the 
file and reading the file date.
You may also check if the file date you've read is close to the saving date 
(but I guess you will run into problems it the server has another system time 
than the client (?)).

Comment 3 Olaf Graf

2002-06-17 03:51:47 EDT

PS: You should also check the samba logs on the server for problems, in our
installation I found a lot I had to fix first (to many files open, no locks 
available, failed to set gid, etc.).

Comment 4 Neil Swingler

2002-06-17 04:09:53 EDT

Olaf sent me his version of resources.jar based on the 06072002 build.
This cured the problem.

I then tried patching the F3 build with the new CoreFileSystemLibrary.class.
Then the problem came back.

Comment 5 Neil Swingler

2002-06-17 04:27:52 EDT

Ignore that. I didn't patch the F3 jar correctly. Now it works
in the F3 resources.jar

Comment 6 Neil Swingler

2002-06-17 10:55:20 EDT

Still getting sporadic problems. This would be consistent with
the problem being a timing issue.

Comment 7 DJ Houghton

2002-06-17 12:06:08 EDT

Note that if you run build F3 with a resources.jar from 20020607 then you run 
the risk of corrupting your workspace as workspace data file formats are not 
forwards compatible.

Let me summarize what you are saying, please correct me if I am wrong.

- 20020607 -> problems
- 20020607 with renamed DLL -> problems
- 20020607 with unchanged DLL and "hasNatives=false" -> it works ok
- F3 -> problems
- F3 with renamed DLL -> problems
- F3 with unchanged DLL and "hasNatives=false" -> problems

Note that renaming the DLL is equivalent to setting hasNatives to false. When 
the DLL is not found then the resources plug-in reverts to java.io.File 
behaviour.

Comment 8 Neil Swingler

2002-06-17 13:32:26 EDT

Sorry to be confusing.
I built my own version of FileSystemResourceManager
and patched the F3 resources.jar.
This worked for most of the day and then the save problems
started again so I guess it just affected the timing enough
to make a difference sometimes.

I don't know why renaming the dll didn't give the same effect.
I saw the warning in the log so it definitely didn't find it.

I think you need to ensure that a different timestamp is recorded
after a save, looping if necessary.

Comment 9 Neil Swingler

2002-06-18 07:23:11 EDT

I have a solution. See bug 16280

Comment 10 Neil Swingler

2002-09-27 09:48:43 EDT

Suggest you close this as duplicate of bug 16280

Comment 11 DJ Houghton

2002-09-27 11:08:16 EDT


*** This bug has been marked as a duplicate of 16280 ***