Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

io.mkdirP throws "EPERM: operation not permitted" for root directories on Windows #1422

Open
tusharsnx opened this issue May 14, 2023 · 2 comments · May be fixed by #1423
Open

io.mkdirP throws "EPERM: operation not permitted" for root directories on Windows #1422

tusharsnx opened this issue May 14, 2023 · 2 comments · May be fixed by #1423
Labels
bug Something isn't working

Comments

@tusharsnx
Copy link

tusharsnx commented May 14, 2023

Describe the bug
io.mkdirP throws EPERM: operation not permitted error for root directories (e.g. C:\) on Windows even if it already exists.

In the node's official docs:

On Windows, using fs.mkdir() on the root directory even with recursion will result in an error

With fs.mkdir which mkdirP uses for its impl, the EPERM error is expected when path is root directory even if it exists on Windows. Most of the third party actions which uses @actions/io does not account for this behaviour and calls mkdirP unconditionally without checking/handling the error. This is also the case with @actions/io, @actions/cache, @actions/artifact, @actions/tool-cache.

mkdirP should behave consistently across platforms.

To Reproduce
Steps to reproduce the behavior:
Running below snippet would lead to error:

const io = require("@actions/io")
await io.mkdirP("C:\\")

Expected behavior
mkdirP shouldn't throw if path already exists (this is already true for Linux).

Screenshots
using "actions/download-artifact" (which internally uses io.mkdirP) fails to run when path is C:\, or D:\:

Screenshot 2023-05-14 213225

for a job step:

...
- uses: actions/download-artifact@v3
  with:
    name: chromium
    path: C:\
...
@tusharsnx tusharsnx added the bug Something isn't working label May 14, 2023
@tusharsnx
Copy link
Author

tusharsnx commented May 17, 2023

Seems like #444 (#781) broke io.mkdirP, particularly with the removal of these lines.

fs.stat'ing throws no error when the drive exists. So the default: case would've gracefully handled all EPERM errors in these cases.

image

ping @cory-miller @vmjoseph @thboop Can you or someone else have a look on this?

@tusharsnx
Copy link
Author

Do we have any updates on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant