Failed to Lock when fetching lib

[MartinNowak]

Windows 10
Dub: 1.3.0

cmd: dub run --build=debug --arch=x86 --compiler=dmd

Fetching libevent 2.0.2+2.0.16 (getting selected version)...
Failed to lock 'C:\Users\User Name\AppData\Roaming\dub\packages\libevent-2.0.2_2.0.16\libevent.lock'.

on dub.json:
"dependencies": {
     "requests": "~>0.3.2",
     "htmld": "~>0.2.16"
}

Maybe is relate to long path names?

[SrMordred]

Ok it´s path related.
resolved when adding:
--cache=local or
--cache=system

I believe its long path or the space on the user name that cause the issue.

[MartinNowak]

Seems like we sometimes leave those lock files around on aborted dub runs, maybe related to a CTRL+C abort (which doesn't cleanup).
What we could prolly try, instead of dealing with SIGINT on all platforms, is always downloading+extracting to tempfolder, then attempting an atomic folder rename.
Could be a bit wasteful for CI systems running multiple parallel instances of dub.
Alternatively having PID/expiration files that allow to remove stale locks would be an options as well.
Or maybe better use native OS locks that hopefully automatically unlock when a process exits.

So far we didn't have any reported issues with https://github.com/dlang/druntime/blob/2db828bd4f21807254b770b3ec304f14596a9805/src/rt/cover.d#L399, so that could make a better replacement.

[MartinNowak]

Dub's current lockFile is here.

[coveralls]

Coverage increased (+0.03%) to 61.663% when pulling b4275e6 on MartinNowak:fix1149 into 13581f8 on dlang:master.

[dlang-bot]

Thanks for your pull request, @MartinNowak!

[s-ludwig]

Fails on 2.066 and below -> std.algorithm : move

[s-ludwig]

Looks good. I can also confirm that I ran into this a few times when I cancelled a package download using Ctrl+C.

[MartinNowak]

Yikes, stupid dlang/dlang-bot#69, hope the tests will be all right.

[wilzbach]

Yeah seems like stable didn't had required CI checks.
I just enabled them for now.