Bug 296799

Comment 1 Paul Slauenwhite 2009-12-03 08:31:38 EST

In addition, there are several tests in the org.eclipse.hyades.test.execution.local package of the org.eclipse.hyades.execution plug-in that are not included in the TPTP JUnit/Plug-in test bucket:

/org.eclipse.hyades.execution/src-local/org/eclipse/hyades/test/execution/local/FileManagerExtendedTest.java
/org.eclipse.hyades.execution/src-local/org/eclipse/hyades/test/execution/local/FileTransferTest.java
/org.eclipse.hyades.execution/src-local/org/eclipse/hyades/test/execution/local/Test.java

Comment 2 Paul Slauenwhite 2009-12-03 08:56:50 EST

Note, this is blocking the TPTP BVTs (JUnit Plug-in and AGR tests).

The cause may be that the file service implementation is not deleting all of the files before attempting to delete the directory.  For example:

public static void deleteContent(File curr) 
	{
		if (curr.exists())
		{
			if (curr.isDirectory()) 
			{
				File[] children = curr.listFiles();
				if (children != null) {
					for (int i = 0; i < children.length; i++) 
					{
						deleteContent(children[i]);
					}
				}
			}
			curr.delete();
		}
	}

Comment 3 Kathy Chan 2009-12-08 09:54:23 EST

Jonathan,

Please take a look for TPTP 4.6.2.

Comment 4 Jonathan West 2009-12-13 21:39:37 EST

Thanks Paul, I have been able to reproduce with a simple test case. Issue is due to the native Hyades file server's incorrect implementation for the delete directory command. I am working on a multi-platform implementation for this in the AC.

Comment 5 Kathy Chan 2010-01-04 12:48:36 EST

Deferring to TPTP 4.7.

Comment 6 Kathy Chan 2010-01-04 12:51:04 EST

Jonathan has a solution which would work on Linux but would cause a build issue on Windows.  We need to resolve that build issue first before checking the fix in.

Comment 7 Paul Slauenwhite 2010-02-01 09:14:23 EST

What is the status on this defect for TPTP 4.7?

Comment 8 Jonathan West 2010-02-02 09:55:37 EST

Fix is available, I found a workaround to updating the build, awaiting time to test and commit.

Comment 9 Paul Slauenwhite 2010-02-03 12:17:05 EST

Jonathan, we are also seeing an odd behavior with:

org.eclipse.hyades.execution.core.file.IFileManager.deleteFile(String)
org.eclipse.hyades.execution.core.file.IFileManagerExtended.deleteFile(FileIdentifierList)

It appears that these methods are asynchronous since some files still exist after the call returns.  The work-around is to delay after the call to ensure all of the files are deleted.  Shouldn't these methods be blocking like the putFile/getFile methods?

See the /org.eclipse.hyades.test.core.tests/junit/harness/Test.Harness.JavaExecutionDeploymentAdapter.Test.testsuite for more details.

Comment 10 Jonathan West 2010-02-16 11:13:10 EST

Created attachment 159204 [details]
Patch to native file server

Comment 11 Jonathan West 2010-02-16 11:15:51 EST

(In reply to comment #9)
> Jonathan, we are also seeing an odd behavior with:
> 
> org.eclipse.hyades.execution.core.file.IFileManager.deleteFile(String)
> org.eclipse.hyades.execution.core.file.IFileManagerExtended.deleteFile(FileIdentifierList)
> 
> It appears that these methods are asynchronous since some files still exist
> after the call returns.  The work-around is to delay after the call to ensure
> all of the files are deleted.  Shouldn't these methods be blocking like the
> putFile/getFile methods?
> 
> See the
> /org.eclipse.hyades.test.core.tests/junit/harness/Test.Harness.JavaExecutionDeploymentAdapter.Test.testsuite
> for more details.

The behaviour of the native file server implementation is the same as the Java file server implementation that was previously in use. Joe Toomey may know more about why the delete operation is non-blocking on the Java side.

Comment 12 Jonathan West 2010-02-16 11:17:53 EST

Patch checked into HEAD.

Comment 13 Paul Slauenwhite 2010-02-17 11:45:37 EST

(In reply to comment #11)
> (In reply to comment #9)
> > Jonathan, we are also seeing an odd behavior with:
> > 
> > org.eclipse.hyades.execution.core.file.IFileManager.deleteFile(String)
> > org.eclipse.hyades.execution.core.file.IFileManagerExtended.deleteFile(FileIdentifierList)
> > 
> > It appears that these methods are asynchronous since some files still exist
> > after the call returns.  The work-around is to delay after the call to ensure
> > all of the files are deleted.  Shouldn't these methods be blocking like the
> > putFile/getFile methods?
> > 
> > See the
> > /org.eclipse.hyades.test.core.tests/junit/harness/Test.Harness.JavaExecutionDeploymentAdapter.Test.testsuite
> > for more details.
> 
> The behaviour of the native file server implementation is the same as the Java
> file server implementation that was previously in use. Joe Toomey may know more
> about why the delete operation is non-blocking on the Java side.

Thank Jonathan.

Unfortunately, Joe is no longer with the TPTP project.  I have opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=303077 to investigate in the future.

Comment 14 Paul Slauenwhite 2010-03-01 12:15:19 EST

Verified in TPTP-4.7.0-201002281900 by launching a TPTP JUnit Plug-in test with a workbench location with the clear configuration area/workspace options set.

Closing.