Re: [jgit-dev] Missing tree during self-tests on NonStop

["Randall S. Becker" <rsbecker@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: Shawn Pearce [mailto:spearce@xxxxxxxxxxx]
> Sent: March 2, 2015 8:23 PM
> To: Randall S. Becker
> Cc: jgit-dev
> Subject: Re: [jgit-dev] Missing tree during self-tests on NonStop
> 
> On Wed, Feb 25, 2015 at 2:54 PM, Randall S. Becker
> <rsbecker@xxxxxxxxxxxxx> wrote:
> > I have a second issue that I am trying to resolve for our NonStop port. This
> one is a failure in both GitConstructionTest and PushCommandTest. Both have
> the virtually the same stack trace and look a little (maybe) like bugs 445744
> and 422988. Both tests point to the same missing tree id (4b825dc6...). It
> seems like something in the FileObjectDatabase hierarchy is not liking what the
> platform is doing with java.io.File, but I am looking for a pointer to where to
> look next.
> >
> > testClose(org.eclipse.jgit.api.GitConstructionTest)  Time elapsed: 9.15 sec
> <<< ERROR!
> > org.eclipse.jgit.api.errors.JGitInternalException: Missing tree
> > 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> 
> My first check would be to look at the test repository on disk and see if
> $GIT_DIR/objects/4b/825dc642cb6eb9a060e54bf8d69288fbee4904 exists and
> is a valid Git object. It seems there are some issues creating or reading files
> through java.io due to Java doing "extra special logic"
> on your platform. :(

I do know that the platform's JVM file create mode 755 instead of 644 by default, although I already changed FileUtils to explicitly remove execute access added by this platform's JVM. What I am suspecting, at this point, is that one or more of the following are creating commit misidentification problems for the tests, based on my previous findings on JDK 1.6 security assumptions by JGit invoking File.createNewFile() instead of FileUtils.createNewFile() below:

RebaseCommand.java:                  new File(rewrittenDir, commit.getName()).createNewFile();
GC.java:           if (!tmpIdx.createNewFile())
GC.java:           if (!tmpBitmapIdx.createNewFile())
LockFile.java:     if (lck.createNewFile())
InitCommandTest.java:           someFile.createNewFile();
GcKeepFilesTest.java:          assertTrue(keepFile.createNewFile());
RefDirectoryTest.java:         assertTrue(packedRefs.createNewFile());

If these are the issue, it is no trouble to change them but I think that using FileUtils might be more appropriate instead of java.io.File.