commandline call of ide disturbs FileTypeIndex? Follow

Is the project structure (content roots etc.) setup correctly? Do other indexes work as expected?

you mean the project structure of my plugin  or the one i test my plugin on? 

if the first i am fairly confident that the answer is yes cause the plugin otherwise works. 

if you mean the later i am absolute certain that yes cause the same call works perfectly fine if called from an action instead of the application starter main method.

other indexes don't get called in neither mode of operation. So i can't confirm nor deny.

Please check with FileNameIndex to check finding known file in your loaded project works

if started from anaction the FileNameIndex finds two files (like expected). If the plugin is started from command line via the Appstarter impl the FileNameIndex finds 0 files. 

Same project both cases 

So the problem is most probably related with your project setup/loading from commandline.

its the exact same setup as from the anaction.

Project project = ProjectUtil.openOrImport(Path.of(filepath));

Both just execute this line and directly afterwards 

PsiFile[] file = FilenameIndex.getFilesByName(project, "test", GlobalSearchScope.projectScope(project));
FileWriter File = new FileWriter(project.getBasePath().concat("/FileIndex " + file.length + " .txt"));
File.write(file.length);
File.close();

project is correctly initialized in both i checked 

Please see com.intellij.codeInspection.InspectionApplicationBase#openProject as reference

probably adding this line in your ApplicationStarter should help

ApplicationManager.getApplication().invokeAndWait(() -> VirtualFileManager.getInstance().refreshWithoutFileWatcher(false))

in order to better debug i wrote a new appstarter implementation. 

@Override
public void main(@NotNull List<String> args) {

    try{
        final ApplicationEx application = (ApplicationEx) ApplicationManager.getApplication();
        application.setSaveAllowed(false);
        Project project = ProjectUtil.openOrImport(Path.of("*projectpath*/untitled1"), null , false);

        if (project == null) {
            FileWriter error = new FileWriter("*projectpath*/untitled1/error.txt");
            error.write("error");
            error.close();
            System.exit(0);
        }

        FileWriter File = new FileWriter("*projectpath*/untitled1/itworked.txt");
        File.write(project.getBasePath());
        File.close();

        application.invokeAndWait(() -> VirtualFileManager.getInstance().refreshWithoutFileWatcher(false));
        PatchProjectUtil.patchProject(project);

        PsiFile[] file = FilenameIndex.getFilesByName(project, "test.js", GlobalSearchScope.projectScope(project));
        FileWriter File2 = new FileWriter(project.getBasePath().concat("/FileIndex " + file.length + " .txt"));
        File2.write(file.length);
        File2.close();

    }catch(Exception e){
    }finally{
        System.exit(0);
    }

}

@Override
public boolean isHeadless() {
    return true;
}

Still the same problem remains that the file index return 0 files. 

after execution in the directory are the "itworked.txt" file with the path entry and an empy "fileindex0.txt" file. 

Ok for everyone interested i eventually figured out what goes wrong tho I have no clue of how to workaround it. I guess here the Jetbrains is asked to correct their environment behaviour. 

The previously described error only happens if the files in question never have been opened by any intellij instance

Meaning if you create a file in a project but dont open said file the FileTypeIndex doesn't recognize this file. 

So far so weird but here it gets complicated. 

if the FileTypeIndex gets called by an AnAction it does recognize the (till then) unopened file after and only after the second attempt.

if called by an AppStarter instance it never recognizes the (till then) unopened file.

Conclusion: Way to avoid that error is to open intellij select the project and open the file after that FileTypeIndex (independent of called by AnAction or Appstarter) recognizes said file.

As add on to my last comment here is a possible solution to avoid said problem 

try (Stream<Path> walk = Files.walk(Paths.get(project.getBasePath()))) {
    pathList = walk.filter(Files::isRegularFile).collect(Collectors.toList());
    for(Path path : pathList) {
        fileList.add(VirtualFileManager.getInstance().refreshAndFindFileByNioPath(path));
    }
}catch (Exception e){

}

The code iterates directly through the file Stystem and then just uses the openapi to convert path into virtualfiles