Windows 10 - VS 2015 - Can't install

[Choonster]

luawinmulti version: 491a626d18a888f202879f1becbfbbee5854dba2 Log: https://gist.github.com/Choonster/f1aa26b8eac216eb42ee

I can't seem to get luawinmulti working. I've tried running it in a normal command prompt and Visual Studio's developer command prompt. I've tried granting the Full Control permission to the Users group for the C:\Lua and luawinmulti directories.

Let me know if you need any more information.

[Tieske]

The problem seems to be here; https://gist.github.com/Choonster/f1aa26b8eac216eb42ee#file-luawinmulti_2016-01-16-log-L766-L767 The downloaded luawinmake files should be copied into the respective Lua source trees

It's executing this code; https://github.com/Tieske/luawinmulti/blob/master/scripts/build.bat#L23

but fails, as it reports 0 files copied. Hence the follow on errors where it tries to run luawinmake which isn't in the expected location...

[Tieske]

what files did it download?

This is my structure after running it;

C:\test\luawinmulti>dir
 Volume in drive C is OSDisk
 Volume Serial Number is 8CCF-02F6

 Directory of C:\test\luawinmulti

10-Jan-16  23:43    <DIR>          .
10-Jan-16  23:43    <DIR>          ..
12-Nov-15  07:38               341 COPYING
11-Nov-15  12:21             1,927 COPYING_7z
10-Jan-16  23:43    <DIR>          lua-5.1
10-Jan-16  23:44    <DIR>          lua-5.2
10-Jan-16  23:44    <DIR>          lua-5.3
10-Jan-16  23:43    <DIR>          luarocks
10-Jan-16  23:43    <DIR>          luawinmake
16-Nov-15  16:51             7,674 make.bat
13-Nov-15  22:20             3,827 README.md
10-Jan-16  22:25    <DIR>          scripts
10-Jan-16  22:10    <DIR>          tools
               4 File(s)         13,769 bytes
               9 Dir(s)  42,881,888,256 bytes free

C:\test\luawinmulti>

so 3x Lua, luawinmake and luarocks directories

Also I notice in the scripts the use of the F:\ drive, haven't tested it with that

[Tieske]

And this is what it should report in the output, after Start building...

Start building...
luawinmake\appveyor.yml
luawinmake\README.md
luawinmake\.appveyor\build.bat
luawinmake\.appveyor\install.bat
luawinmake\.appveyor\set_compiler_env.bat
luawinmake\etc\winmake.bat
6 File(s) copied
Cleaning...
Done.

Checking source code to extract Lua version...
Lua version found: 5.1

Testing for MS...

[Tieske]

first line in scripts\build.bat is @echo off can you change it in @echo on and see what it does if you run it again using make --clean?

[Tieske]

Actually I think the problem is here; https://gist.github.com/Choonster/f1aa26b8eac216eb42ee#file-luawinmulti_2016-01-16-log-L58

Caused by this command; https://github.com/Tieske/luawinmulti/blob/master/scripts/download.bat#L52

It's trying to rename the downloaded directory including a bunch of details into a generic name, and fails. And later on the copy command I mentioned above fails, because it cannot find the normalized directory name.

Permission issue?

[Choonster]

I moved luawinmulti to C:\luawinmulti, just in case it was the drive messing things up.

I've uploaded the output of make --clean (with @echo on in scripts\build.bat) and dir here.

It shouldn't be a permission issue, I granted Full Control of C:\luawinmulti to the Authenticated Users and Users groups. The Effective Access tool (Properties > Security > Advanced > Effective Access) says that my current user has access to every permission.

[Choonster]

Actually, it seems to work sometimes. I'll see if I can narrow down what works and what doesn't.

[Choonster]

Running make install on a fresh copy of luawinmulti fails. Running make --clean install after that also fails. (Logs)

Running make --clean install on a fresh copy of luawinmulti followed by the same command twice more also fails. (Logs)

I'm not entirely sure what I did before to make it work. I'll keep trying various things.

[Choonster]

It does seem to be an issue with rename (possibly permissions), but it's not consistent. make install will usually fail to rename one or two directories, but if I keep running it the directories are eventually renamed and the installation succeeds.

[ignacio]

I have the same setup (Windows 10, VS 2015, running the scripts from a drive other than C:) and it worked fine. Can provide logs or try things out if you guys need a third environment.

[ignacio]

Also, any particular antivirus software or something like that that could cause this erratic behaviour?

[Tieske]

wild guess; can you add the following line just before the rename command?

ping -n 6 localhost >nul

(will sleep for 5 seconds; 6 pings, on a 1 second interval)

Guess being that somehow the process writing to the folder has not yet released all filehandles or something and hence Windows cannot rename a folder that is considered to be still in use.

[Tieske]

and one more.... the included 7zip version (which I just lazily copied from LuaRocks), is an old 9.1beta version. If my previous wild guess is correct, then the 7zip executable is probably the culprit. So you could download a newer version and see whether that fixes things.

please try and let us know the results

[Choonster]

Just updating to 7-Zip 15.14.0.0 Extra fails with the same inconsistent "Access is denied" errors. (Log)

Updating 7-Zip and adding the waits succeeds. (Log)

Just adding the waits succeeds. (Log)

[Choonster]

Running the original 491a626d18a888f202879f1becbfbbee5854dba2 commit with McAfee's Real-Time Scanning disabled succeeds. (Log)

So it looks like McAfee was locking up the directories as they were extracted and adding waits gives it enough time to release the locks.

[Tieske]

I should have known, I've seen similar issues with dropbox and tortoisegit, which both extensively scan files in the background.

Maybe we should bypass the renaming all together and try to extract the files directly into the correctly named folder. That would solve the whole issue.

Thx a lot for testing!

[Tieske]

closing this in favor of #4

[Choonster]

No problem, I'l glad you're sorting this out.

[ignacio]

Meh, one more for the "weird behaviours caused by antivirus" :)

[Tieske]

@ignacio @Choonster way over due, but finally fixed (with some others) in master

[Choonster]

Thanks.