Hi, I found a difference between Java and C# implementations. Specifically, in the method GetCanonicalPath (getCanonicalPath in Java) from the class FSDirectory, Lucene creates a File object but not a file in the FS (the comment in the head of that method is wrong, because constructing a File object does not create it in the FS), while the .Net version was creating it. Fixing that difference, the two mysterious tests pass.
In my most recent PR I changed that. Guido -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Itamar Syn-Hershko Sent: Tuesday, January 27, 2015 1:29 PM To: [email protected] Subject: Re: About two Store failing tests If you mean: // LUCENENET TODO mysterious failure - FSDirectory recreates the folder by design, not sure why this passes for Java Lucene That was me. I pinged someone from Java Lucene to get some reasoning but never heard back. Will try again now. Another option is to debug line-by-line and side by side the .NET and the Java code for the same test, and see maybe they are taking different code paths. I'm assuming that'd be the case. Then try understanding why... -- Itamar Syn-Hershko http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer & Consultant Lucene.NET committer and PMC member On Tue, Jan 27, 2015 at 9:43 PM, Guido Tagliavini Ponce < [email protected]> wrote: > Hi devs, > > This email is about two of the Store's tests: > > * core/Store/TestNRTCachingDirectory.cs - TestNoDir > > * core/Store/TestFileSwitchDirectory.cs - TestNoDir > > Essentially, both create temporary directories, delete them, and use > its information to create more specific directories > (NRTCachingDirectory and FileSwitchDirectory). Just after constructing > the latter ones, they assert that those directories do not exist which > will be false because the constructors create the directories if they > do not exist (in the case of NRTCachingDirectory, the directory is > created before calling the constructor using the NewFSDirectory > method). Another person already pointed out this in a comment in the first > one of the tests. > > The easy fix for this would be adding deletion instructions after the > second round of constructions. But by doing this we could be hiding > some other problem under the rug. Two possibilities that come to my mind: > > 1. They forgot to delete the directories just before the assertions. > This seems unlikely to be happening because it would be an obvious bug. > > 2. The directories' implementations changed over the time but they > forgot to change the tests: Maybe, initially, they didn't create the > directories if they didn't exist beforehand. > > Knowing the goal of the test could help deciding. If they wanted to > test if they could delete those type of directories, then option 1 > could be the right one. If they wanted to test that they don't create > directories if they don't exist, the other option would fit better with it. > > Am I missing out some other possibility? What should we do with those > tests? > > Best regards, > > Guido >
