You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Dawid Weiss (JIRA)" <ji...@apache.org> on 2018/03/13 13:26:00 UTC

[jira] [Commented] (LUCENE-8203) Windows failures when removing test directories

    [ https://issues.apache.org/jira/browse/LUCENE-8203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396931#comment-16396931 ] 

Dawid Weiss commented on LUCENE-8203:
-------------------------------------

I don't know what's causing this. Could be an external process doing something in the directory (defender, some other scanning software)? This is what it looks like.

bq. It's also surprising how it sometimes fails with a DirectoryNotEmptyException without reporting issues about deleting inner files of the directory.

The test rule in {{TestRuleTemporaryFilesCleanup}} doesn't list them... and looking at the implementation of afterAlways I think you could try to scan it again and see what exactly is remaining. The implementation of temp. directory supplier in randomizedtesting does this sort of thing and reports those files (I can't remember why we have a separate facility for this in Lucene; perhaps for flexibility or to substitute different fs implementations).


> Windows failures when removing test directories
> -----------------------------------------------
>
>                 Key: LUCENE-8203
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8203
>             Project: Lucene - Core
>          Issue Type: Test
>            Reporter: Adrien Grand
>            Priority: Minor
>
> I was looking at Lucene failures of Policeman Jenkins' Windows job (https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows) and they all fail  when cleaning up temporary files/dirs used for testing, eg.
> {noformat}
> [junit4] ERROR   0.00s J1 | TestBoolean2 (suite) <<<
>    [junit4]    > Throwable #1: java.io.IOException: Could not remove the following files (in the order of attempts):
>    [junit4]    >    C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001: java.nio.file.AccessDeniedException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001\tempDir-001
>    [junit4]    >    C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001: java.nio.file.DirectoryNotEmptyException: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\J1\temp\lucene.search.TestBoolean2_B7B1F66EB9785AE1-001
>    [junit4]    > 	at __randomizedtesting.SeedInfo.seed([B7B1F66EB9785AE1]:0)
>    [junit4]    > 	at org.apache.lucene.util.IOUtils.rm(IOUtils.java:329)
>    [junit4]    > 	at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Has anyone ideas what the problem is? At first sight it looks:
>  - not due to unclosed index inputs or MockDirectoryWrapper would barf too
>  - not related to the unmap hack since we have failures on tests that do not use MmapDirectory at all like TestNIOFSDirectory
>  - not due to the fact that we do not release resources in a try/finally or try-with-resources block or junit would report the exception that prevented the dir/input from being closed as well
> It's also surprising how it sometimes fails with a DirectoryNotEmptyException without reporting issues about deleting inner files of the directory.
> I don't have much background on this issue so I could easily have missed something.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org