ENOENT: no such file or directory while attempting to upload

[iamrecursion]

Describe the bug
We're using upload-artifact to upload our packages as part of our workflow. This has, historically, worked absolutely fine on Windows, Linux, and macOS, but recently has started failing on Windows only with the following:

ENOENT: no such file or directory, realpath 'D:\a\enso-staging\enso-staging\repo\built-distribution\enso-engine-0.2.19-SNAPSHOT.2021-08-03-windows-amd64\enso-0.2.19-SNAPSHOT.2021-08-03\lib\Standard\Table\0.1.0\polyglot\java\xmlbeans-5.0.1\org\apache\xmlbeans\metadata\attribute\http_3A_2F_2Fwww_2Ew3_2Eorg_2FXML_2F1998_2Fnamespace'

Curiously enough, it works during our release workflow, but not our nighttly workflow, and we can't find any material difference between the two that would contribute to this.

Version

• V1
• V2

Environment

• self-hosted
• Linux
• Windows
• Mac

Run/Repo Url
You can find a failing run here.

How to reproduce
It fails consistently when running that workflow.

[radeusgd]

A difference between the release workflow and the nightly workflow is that the version string (which is included twice in the mentioned path) is longer - release is something like 0.2.22 and nightly is 0.2.22-SNAPSHOT.2021-08-07. Since this only happens on Windows, it may be related to some issues with handling very long paths on Windows.

[radeusgd]

I have confirmed that the file for which ENOENT is raised does in fact exist, so it seems that somehow the error is caused by the long path.

After some digging I have found that the offending call seems to be the promise returning fs.promises.realpath(...) called from globber.glob.

I was able to replicate this in Node REPL too, calling fs.promises.realpath(longpath) yielded the same error. Interestingly, calling the 'classic' callback-based variant fs.realpath on the same path was returning the correct result, so this looks like it may be a bug in Node's filesystem library.

To try to reproduce this you may create a directory hierarchy D:\a\enso-staging\enso-staging\repo\built-distribution\enso-engine-0.2.19-SNAPSHOT.2021-08-03-windows-amd64\enso-0.2.19-SNAPSHOT.2021-08-03\lib\Standard\Table\0.1.0\polyglot\java\xmlbeans-5.0.1\org\apache\xmlbeans\metadata\attribute\http_3A_2F_2Fwww_2Ew3_2Eorg_2FXML_2F1998_2Fnamespace and try running fs.promises.realpath on this path.

[radeusgd]

Reported this in the Node repo: nodejs/node#39721

[laeubi]

We have a similar problem in the PDE project, is there any ETA for a fix, any information to provide or anything else to push this forward?

[laeubi]

Is there any ETA when this get fixed? This currently makes the Windows artifacts upload unusable for us.

[laeubi]

Still an issue :-(

[HannesWell]

Is there any plan when this will be fixed?

[kwin]

This should be fixed in the already released NodeJS 16.18.0 (nodejs/node@8d259e6086). Currently the Windows Runners come with NodeJS 16.18.1: https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md and https://github.com/actions/runner-images/blob/main/images/win/Windows2019-Readme.md. See also https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V16.md#16.18.0

[kwin]

Although the upstream Node JS issue (nodejs/node#39721) is fixed with 16.8.0 we are still running into this issue (with a GH runner on Windows version: '2.299.1', using Node JS 16.8.1). Seems that there is some other issue with this action not related to the Node JS issue.

The failed run is at https://github.com/eclipse-m2e/m2e-core/actions/runs/3803309550/jobs/6469609937

[CrazyHZM]

Is there any progress?

[Piedone]

actions/checkout#955 would help here.

[scrnjakovic]

Any progress with this?