Windows: rocks.toml contents being erased on update/sync/install

[MeguminSama]

I actually found this yesterday while figuring out #513 but I wanted to investigate further before opening an issue.

rocks.toml's contents gets erased whenever it gets written to (e.g. with :Rocks install). This means that if you do :Rocks sync, rocks uninstalls itself (lol) as it's not in the toml file.

rocks.log is also empty.

I'm struggling to narrow down the issue, but when I run :Rocks install rocks.nvim, I see the following in process monitor:

As it opens a pipe, I can assume it's happening in fs.lua in the fs.write_file function, where it opens a pipe. It's not immediately obvious to me why it might not be writing to the file though. Could be a problem with whatever is calling fs.write_file.

I'll keep looking but I am struggling to figure out what's happening.

[MeguminSama]

Update:

rocks.log now has some logs...

[START][2024-08-24 15:44:58] rocks.nvim logging initiated
ERROR | 2024-08-24 15:45:08 | ...a\Local\nvim-data\rocks\rocks_rtp/lua/rocks/luarocks.lua:63 | luarocks CLI FAILED
ERROR | 2024-08-24 15:45:08 | ...a\Local\nvim-data\rocks\rocks_rtp/lua/rocks/luarocks.lua:64 | 

Error: No results matching query were found for Lua 5.1.

To check if it is available for other Lua versions, use --check-lua-versions.

ERROR | 2024-08-24 15:45:08 | ...im-data\rocks\rocks_rtp/lua/rocks/operations/helpers.lua:93 | Failed to install rocks.nvinm

I noticed that in nvim-data/rocks/bin/luarocks.bat it contains:

@echo off
setlocal
set "LUAROCKS_SYSCONFDIR=C:\Program Files\luarocks"
"C:\Users\megu\AppData\Local\nvim-data\rocks\lib\luarocks\rocks-5.1\luarocks\3.11.1-1\bin\luarocks" %*
exit /b %ERRORLEVEL%

Firstly, C:\Program FIles\luarocks doesn't exist, and secondly, "C:\Users\megu\AppData\Local\nvim-data\rocks\lib\luarocks\rocks-5.1\luarocks\3.11.1-1\bin\luarocks" isn't executable (windows moment)

Prefixing that line like so causes the error in rocks.log to go away, but doesn't fix the rocks.toml getting erased.

- "C:\Users\megu\AppData\Local\nvim-data\rocks\lib\luarocks\rocks-5.1\luarocks\3.11.1-1\bin\luarocks" %*
+ lua "C:\Users\megu\AppData\Local\nvim-data\rocks\lib\luarocks\rocks-5.1\luarocks\3.11.1-1\bin\luarocks" %*

[MeguminSama]

Looks like it could be because I use luajit instead of lua 5.1.

I tried reinstalling rocks with lua 5.1 but get some errors when installing.

fzy 1.0.3-1 depends on lua >= 5.1 (5.1-1 provided by VM: success)
mingw32-gcc -O2 -c -o src/fzy_native.o -IC:\Program Files (x86)\LuaRocks/include src/fzy_native.c -DLUA_COMPAT_5_1
'mingw32-gcc' is not recognized as an internal or external command,
operable program or batch file.

When using luajit, it said something along the lines of "using a lua alternative" if it couldn't find/compile fzy. With lua 5.1 however, it seems to just break because of no mingw32-gcc.

On windows, mingw32-gcc is usually provided as i686-w64-mingw32-gcc.exe or x86_64-w64-mingw32-gcc.exe, however renaming either of these causes a variety of painful compiler errors.

[mrcjkb]

I noticed that in nvim-data/rocks/bin/luarocks.bat

That script seems to be broken on Windows. It's part of the luarocks dependency we bundle with rocks.nvim so that we can ensure a compatible version is installed.

If you're having issues with it, you can try setting vim.g.rocks_nvim.luarocks_binary.

We also made a scoop bucket for luarocks, built against the Lua 5.1 headers and bundled with Lua 5.1. Some people have reported better success with that.

Just a heads up: I'm about to go on vacation, so I'll have limited time to respond in the next few weeks.

[MeguminSama]

@mrcjkb I actually found the original issue after a lot more debugging. It was caused by the use of pipes in fs.lua:

  uv.fs_open(location, mode, tonumber("644", 8), function(err, file)
        if file and not err then
-            local file_pipe = uv.new_pipe(false)
-            ---@cast file_pipe uv_pipe_t
-            uv.pipe_open(file_pipe, file)
-            uv.write(file_pipe, contents, function(write_err)
+            uv.fs_write(file, contents, function(write_err)

Removing the pipe and using fs_write(file instead of write(file_pipe has fixed the issue completely. The toml file now saves, updates, and syncs correctly.

I'll open a PR