Re: [jgit-dev] FileMode values failing self-tests on NonStop

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Tue, Feb 24, 2015 at 9:01 PM, Randall S. Becker
<rsbecker@xxxxxxxxxxxxx> wrote:
> Brief intro - I am involved in porting git, JGit, and Gerrit over to the HP
> NonStop OSS platform. Git went pretty well, so far anyway, although we have
> timeout issues from EGit (not relevant to this). For JGit, we are currently
> building for JDK 1.6, and it is not passing 16 AddCommand tests, due to file
> mode mismatches, for example:
>
> testAddExistingSingleBinaryFile(org.eclipse.jgit.api.AddCommandTest)  Time
> elapsed: 1.936 sec  <<< FAILURE!
> org.junit.ComparisonFailure: expected:<[a.txt, mode:100[644], content:row1
> row2...> but was:<[a.txt, mode:100[755], content:row1
> row2...>
>         at org.junit.Assert.assertEquals(Assert.java:115)
>         at org.junit.Assert.assertEquals(Assert.java:144)
>         at
> org.eclipse.jgit.api.AddCommandTest.testAddExistingSingleBinaryFile(AddComma
> ndTest.java:179)
>
> The platform is a Big-Endian Itanium with a POSIXesque file system. A visual
> inspection of the FileMode, AddCommand, NB, IO code were unrevealing as to
> why the mode test would fail. All other non-mode-related tests pass, except
> GitConstructionTest, which I am just guessing may be related. This applies
> from HEAD back to at least commit 8899006. Has this happened elsewhere?

I haven't seen this specific failure before.

It looks like JGit is detecting a file is executable when the test
expected it to be a regular file. On Windows this was always fuzzy
because the concept of "executable" isn't like on UNIX systems. The
core.filemode config variable should be auto-detected during
repository creation and used during things like AddCommand to decide
if it should trust the filesystem's concept of "executable". On UNIX
systems, yes, on Windows systems typically no, because its too likely
to give you bad results.

This smells like the Windows failure mode when core.filemode isn't
honored and the code is just blindly trusting the filesystem's concept
of executable, and the filesystem is falsely claiming everything is
executable.

I know nothing of HP NonStop, so I don't know what "executable" means
there, or how the Java APIs might be showing that bit about a file to
JGit.