[Windows] Cannot retrieve roots from FS (EPERM for 'Documents and Settings') #631
Comments
That means, we cannot get the workspace root on Windows. Nice. |
|
My super complex script fails with the same problem.
const fs = require("fs");
const a1 = fs.readdirSync("C:\\");
console.log(a1);
const a2 = fs.readdirSync("C:\\Documents and Settings");
console.log(a2); |
kittaakos
changed the title
|
It fails on Windows 10 inside both VirtualBox and VMWare Fusion. (node 8.2.1 and 8.6.0) |
|
Is it that we should not use Document & Settings to store app data ? |
|
@marcdumais-work, the above error is gone, if I execute the module from a terminal I have opened as an administrator. This "trick" has no effect when running Theia. |
No. And we do not store anything but trying to create a tree from the file-resource hierarchy. |
|
Rigth but humm why is the hiearchy starting there again ? :) |
|
I do not understand this. |
|
I mean why is the workspace root Document & Settings ? Or is it C: and it tries to do a recursive tree from there ? |
|
Correct. |
This might explain why it's working a little better when I start Theia on D:, which on my machine is a pure data drive, without "Documents & Settings", etc. |
|
@marcdumais-work, could you please try it again after turning off the Windows Defender? Thanks! |
|
Or just try to ignore |
|
Should we not just recover from an exception like that list the dir name, do not go further and continue making the tree ? |
|
I do not think that would solve the issue. If we would do that, then the user would see a tree with the root |
|
@kittaakos Ok, I have added the exclusion. I get the following error in the fronte-end, when clicking on "open Workspace" : I get the same when altogether disabling Windows Defender |
|
@kittaakos it should see the C children but not the children of Document & Settings no ? |
|
From your script C: is working fine... |
|
Do you have any antivirus program running? Some people recommend to turn that off too. Disabling the Windows Defender did not help here either. The only workaround I have found so far is to run the terminal as an administrator. |
True. But what could the user do with the |
|
Why are we trying to figureout a workaround ? Theia should not need admin to run. |
|
@kittaakos no I think it's just Windows Defender on that machine. |
It is fine if there a dir we are not allowed to read. |
|
@marcdumais-work, thanks for checking! |
Please define not allowed to read, I can read it from the terminal, a windows commander, or a windows explorer. I cannot read it from Node.js. |
|
@akosyakov from a git bash teminal, I can't access c:\pagefile.sys, the same file as in the error I got above:
|
|
@kittaakos but you are admin on that terminal/windows explorer no ? Unless node is not running as the current user but I doubt it ? |
|
I think unlike on linux osx/linux when you start something from an admin Git Bash the children are not admin but are from the current user. |
kittaakos
added a commit
that referenced
this issue
Oct 16, 2017
|
Although, the issue seems to be fixed with the changes, it reveals other problems on Windows: |
|
Indeed a problem there, you should have access to those, is listing working but not watching ? |
|
I can transform the error message into a warning and omit the stack trace. Any other ideas? |
|
We need to figure out what the perm issue is ? |
|
I do not understand this, could you please elaborate? I can do the following; in the watcher, when I receive an exception, I can check for the |
kittaakos
added a commit
that referenced
this issue
Oct 16, 2017
Instead of logging an error with its full stack trace, we log a warning when the file change cannot be watched do to insufficient user permissions. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
|
Yes that's fine but I think we need to know why we can't watch for example Maybe we're doing something wrong that will be an issue at some point for a rootdir also? |
I think the problem is somewhere here. Maybe we should use |
|
PR: #643 |
kittaakos
added a commit
that referenced
this issue
Oct 16, 2017
Signed-off-by: Akos Kitta <kittaakos@gmail.com>
but |
kittaakos
added a commit
that referenced
this issue
Oct 16, 2017
Added method for getting the current user's home directory. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
kittaakos
added a commit
that referenced
this issue
Oct 16, 2017
From now on, FS gracefully handles when operation is not permitted or when resource is busy, so that it does not fail when getting file stats. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
kittaakos
added a commit
that referenced
this issue
Oct 16, 2017
From now on the workspace root selector dialog proposes the current user's home directory instead of the FS root. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
kittaakos
added a commit
that referenced
this issue
Oct 16, 2017
kittaakos
added a commit
that referenced
this issue
Oct 16, 2017
Instead of logging an error with its full stack trace, we log a warning when the file change cannot be watched do to insufficient user permissions. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
|
Created #646 about the issue I mentioned before |
kittaakos
added a commit
that referenced
this issue
Oct 17, 2017
Added method for getting the current user's home directory. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
kittaakos
added a commit
that referenced
this issue
Oct 17, 2017
From now on, FS gracefully handles when operation is not permitted or when resource is busy, so that it does not fail when getting file stats. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
kittaakos
added a commit
that referenced
this issue
Oct 17, 2017
From now on the workspace root selector dialog proposes the current user's home directory instead of the FS root. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
kittaakos
added a commit
that referenced
this issue
Oct 17, 2017
kittaakos
added a commit
that referenced
this issue
Oct 17, 2017
Instead of logging an error with its full stack trace, we log a warning when the file change cannot be watched do to insufficient user permissions. Signed-off-by: Akos Kitta <kittaakos@gmail.com>
|
Duplicate of #663 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
On Windows (10) it seems impossible to open a workspace. The "Open Workspace" button is there but pressing it has no effect.
On another Windows 10 machine, I saw yesterday a slightly different behavior: that machine had multiple disks: starting Theia from the first one (C:) had the same issue as above. Starting it from the second disk (D:), the "Open Workspace" button did work, but presented me with a directory selection dialog that contained only the D drive and no sub-directory to select. Chosing the drive "worked" but left me with an empty open workspace, with no file/directories in the file navigator.
The text was updated successfully, but these errors were encountered: