"deleted from disk" every time I compile

I am using theiaide/theia-cpp:next, and using bazel and clang to compile my programs. Every time I compile, it seems to somehow magically “touch” every file (it isn’t actually changing the timestamp) and theia closes all the open tabs. Sometimes, if I am editing a file while it is being compiled, it leaves the tab open with “deleted from disk”. (The file is not deleted).

It can get quite annoying having all working files disappear upon every compile; any ideas?

@realazthat thank you for the discussion, do you happen to have a workspace I may use in order to reproduce the behavior? It’d also be good to determine if the same behavior occurs when using VS Code and if in fact it is the expected behavior from the VS Code extensions.

How do I get it to you?

I don’t have experience with VS code, and its relation to theia; how can I test this?

You can share a link to a GitHub repository where you have the workspace used and the steps to reproduce the problem.

Theia can consume VS Code extensions, and the theia-cpp docker image is an example of a Theia-based application with support for C/C++.

The image includes the vscode-clangd extension to provide language support: https://github.com/theia-ide/theia-apps/blob/b86d86ba43f4c7af87d8a5f4a3c5ea63ef881731/theia-cpp-docker/latest.package.json#L121

I am not sure how I would try to run this in VS code; my machine is Windows, but I am running theia in docker/ubuntu, which has clangd running fine. I have no idea if clangd can even run on Windows native.

It does (https://clangd.llvm.org/installation.html), but maybe when you provide a reproducible setup (workspace and steps), I can verify what is actually happening.

OK, I am trying to reproduce it; I copied my entire directory to pare it down, but I can’t seem to get it to happen again. I guess I’ll just keep programming productively until it happens again.

Hmm, it seems to keep happening in the original location, but it happen at all in a perfectly copied directory.

Hi @realazthat,

That original location, where the problem is reproducible, would it happen to be on an external media/filesystem, that’s mounted as a docker volume so it’s accessible from inside the container? For example a removeable USB drive or network drive?

Nope, it is a subdirectory of my Documents folder. Alas it is still happening, but I can’t bring myself to program in a fake pared down copy for long enough to see if it happens after using it for a while.

Thanks for confirming @realazthat. I suspect that something funky is happening with file watching, in such a situation: Windows host, running a Linux docker container with (presumably) the workspace mounted as a docker volume. My guess is that the file watchers are not behaving correctly, between the Linux-based container and the Windows side of things. The docker volume might not be helping (it has it own limitations).

You could try to have your workspace under WSL instead of on the “Windows” side, as it is now. But I am not sure it will be enough.

Another test is to have a container where you copy the content of your workspace inside, and work from there, instead of using the workspace through a mounted volume. Make sure the copied workspace and its content has sane unix perms, since these can get mangled between windows and linux.

OK for the record let me clarify everything a little more precisely.

  1. I am running the docker under WSL.
  2. The project directory lives under My Documents.
  3. In WSL, I use a symlink as a shortcut to the project directory, so I can CD to it from the WSL home directory.
  4. I am accessing theia from my browser locally.