Open frank-dspeed opened 5 years ago
Is there any chance of getting this fixed? It seems to affect workspaceContains activation event for plugins -- it doesn't fire in theia, while working fine in vscode. I've narrowed it down to workspace.findFiles that returns different results in theia, compared to vscode. It's a fairly basic C project with some build artifacts, file count is 361, so it's not even that big.
Is there any chance of getting this fixed?
@vnfedotov if you're interested, please feel free to provide a pull-request to address the issue.
@vince-fugnitto I'll look into it. Its FileSearchServiceImpl, is it?
@vince-fugnitto I think i've figured it out, but in my case it's a different issue related to ripgrep options, I've opened a new issue: #8669
I am also having troubles with findFiles
using Theia 1.53.2.
It looks like the vscode.workspace.findFiles()
function in Theia respects .gitignore
entries, which prevents files ignored by Git from being found by the function. This differs from VS Code, where findFiles()
does not exclude files in .gitignore
by default, leading to inconsistencies between the two environments.
I've submitted a PR to fix this. See https://github.com/eclipse-theia/theia/pull/14365.
@chroberino Thanks for looking into it. Can you supply us with a git repo or something that reproduces this issue (and ideally the respective arguments for the findFiles
call)? I cannot reproduce this, see discussion over in https://github.com/eclipse-theia/theia/pull/14365.
@msujew, sorry I totally missed your reply/question.
At the moment I don't have a public repo to share. But I can share the method where findFiles
was failing.
Let me explain what I tried to do: I am working on a VS Code extension to support remote debugging with GDB. For this extension I have implemented the following method:
private async generateInitGdb(): Promise<void> {
const workspaceFolder = vscode.workspace.workspaceFolders?.[0].uri.fsPath;
if (!workspaceFolder) {
vscode.window.showErrorMessage("Workspace folder not found.");
return;
}
const directories = new Set<string>();
const searchFiles = async (extension: string) => {
const files = await vscode.workspace.findFiles(`Temp/**/*.${extension}`);
files.forEach(file => {
const dir = path.dirname(file.fsPath);
directories.add(dir);
});
};
await searchFiles('out');
//await searchFiles() for further file extensions of interest
// Check if there are directories to add to solib-search-path
if (directories.size === 0) {
vscode.window.showInformationMessage("No relevant files found; .initgdb file not created.");
return;
}
// Create semicolon-separated list of directories
const solibSearchPath = Array.from(directories).join(';');
const initGdbContent = `set solib-search-path ${solibSearchPath}`;
// Write to .initgdb file
const initGdbPath = path.join(workspaceFolder, '.initgdb');
fs.writeFileSync(initGdbPath, initGdbContent);
vscode.window.showInformationMessage(".initgdb file generated successfully.");
}
Just for the sake of completeness:
import * as vscode from 'vscode';
import * as fs from 'fs';
import * as path from 'path';
The generateInitGdb()
method searches the workspace’s Temp
folder for debugger-relavant files (e.g. files with .out
extension), collects their unique directories, and creates an .initgdb
file that sets GDB's solib-search-path to these directories, helping GDB locate necessary debugging symbols for the project. This method has the issues using vscode.workspace.findFiles()
in Theia, as it respects .gitignore
by default. My .gitignore
file contains a line saying /Temp/
which excludes the whole Temp
folder.
Running my extension in VS Code and triggering this method finds all relevant files in the Temp
folder and properly creates the .initgdb
file.
Removing the line /Temp/
from .gitignore
also allows my extension running in Theia to find all relavant in the Temp
folder and create the .initgdb
file.
Description
when opening a large project lets say a linuxRootFs search in folders or any other search returns no results on any pattern
Reproduction Steps
OS and Theia version: theia next docker Diagnostics: