Maintenance tool error: "Cannot open file "" for writing: No error"

mcleary

@hskoglund No luck clearing the path.

hskoglund

Hmm name collision, interesting...
Ok try to set another, explicit TEMP path, first create a directory (say C:\Temp that's guaranteed to be empty), then try:

set temp=C:\Temp
set tmp=C:\Temp
qt-opensource-windows-x86-5.14.1.exe

mcleary

Same problem. Fortunately if I kill the installer process while this dialog is being displayed I can keep the installation, I just don't have the maintenance tool. This is enough for me to keep working for now.

Thanks for the help

mcleary

Right, so now I can say for sure that there is something wrong with the installer.

I just tried the installer in a brand new machine and I get the same message:

alt text

Right after it finishes downloading the repositories.

Now I am pretty sure it is not just my machine anymore.

hskoglund

Hmm just installed Qt 5.14.1 using the online installer qt-unified-windows-x86-3.2.1-2-online.exe on a Windows 10 PC:
alt text
(I selected only MSVC2017 64-bit and answered No for participating in the telemetry/statistics.)

Maybe it's something with different versions of Windows 10? I have version 19.03 10.0.18362.657 (the version numbers can be seen on the 1st line when you open a CMD window).

Your 2 Windows 10 PCs that go south, are they running the same version of Windows 10?

mcleary

Really appreciate the help.

Is that the online installer? Using the online installer I can't even get to the page to select which Qt version to install.

So one Windows is exactly the same as yours, 19.03 10.0.18362.657

The other one is 19.09 10.0.0.18363.592

hskoglund

Yep it was the online installer. (I can try with the offline version soon.)

So the problem you have when using the online installer, "can't even get to the page..." do you get an error message or does the online installer just die at that point?

mcleary

So, you can see exactly what is happening in this small recording I just did: https://webmshare.com/play/mKdNX

hskoglund

Ok, I can see that the downloading starts with the "Preparing meta information download" but then it dies the same way as the offline installer.

I traced on my Windows 10, it seems that the TEMP and TMP settings are immaterial, the Maintenance Tool always uses C:\Users\Username\AppData\Local\Temp, where Procmon.exe on your PC said "Name collision".

I run Procmon.exe on my Windows 10, after it connects to download.qt.io and downloads the first chunks, it tries to open a temp file to store them in, this is the line on my Procmon (I skipped the leftmost bit of the line for brevity):

... CreateFile   C:\Users\Henry\AppData\Local\Temp\qt-unified-windows-x86-3.FNfLTQ  SUCCESS  Desired Access: Generic Read/Write, Disposition: Create, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, Write, AllocationSize: 0, OpenResult: Created

but I'm guessing if you do the same Procmon trace it will with "Name collision", i.e. this is where you Maintenance Tool takes a dive.

Perhaps your C:\Users\tluis\AppData\LOcal\Temp directory has some problem, what happens if you try to create a file in it, for example:

copy con C:\Users\tluis\AppData\LOcal\Temp\test.txt
A line of text
^Z
          1 file(s) copied.

mcleary

I will check it tonight. Thanks for the advice

mcleary

@hskoglund I can create files normally in the temp directory.

Now, here is the interesting bit, the installer has an option to test the connection to the repositories. If I click to test the connection I get the exact same message "Cannot open file "" for writing: No error". Now, if I delete the temporary file the installer creates when testing the connection, the test passes.

Please take a look in the following recording or the error:

http://webmshare.com/play/Oxq6Y

I am starting to suspect that something with my network is wrong since two machines are showing the same problem. This doesn't explain the problem with the offline installer though.

mcleary

I manage to get a third machine to try. I did the same repository test as described previously and I noticed that for each repository test the installer creates a different temporary in the TEMP folder. For some reason, on my machine, the name of the temporary the installer tries to create is always the same, which doesn't make sense at all.

hskoglund

Curiouser and curiouser! That explains those "Name collisions" in Procmon.

Looks like the random/seed temp filename generator is broken in the Maintenance Tool on your PC. The first thing that springs to mind is the network, using for example the MAC address of your network adapter is the classic way to seed a random generator.

So is your PC a real physical PC or a virtual one? Also if you type ipconfig/all does the output seem reasonable?

Best would be to check the source code for Maintenance Tool's temp filename generator, but Maintenance Tool seems not available as open source? Perhaps might do some disassembly, need some coffee then...

JonB

Have you people looked at the currently on-going https://forum.qt.io/topic/111738/installation-fails-no-file-name-specified ? Perhaps @aha_1980 's https://forum.qt.io/topic/111738/installation-fails-no-file-name-specified/4 ?

mcleary

@JonB Thanks for linking those posts. It seems it is not just a Windows problem after all.

I am using a physical machine yes, the video I posted was on a virtual machine though. However, a laptop I have is running the installer just fine.

I just switched my PC to use wifi and disabled the ethernet adapter but the result is the same, the installer keeps generating the same extension for the temporary file: sZLsZL. On the laptop each time I click to test a repository connection I get a different file.

I will start looking into the QTemporaryFile implementation but another small program I wrote seems to generate temporary files just file.

mcleary

So a little explanation of what the h.. was happening

After my last post, I realised that the Qt Installer wasn't generating a new temporary file resulting in name conflicts as I reported in one earlier post.

This leads me to take a look into QTemporaryFile implementation since I was pretty sure that the installer was using this class to generate new temporary files.

Looking into the source code for QTemporaryFile I found the loop where the random string was being generated. QTemporaryFile can generate unique file names based on a name template defined with X's in a string.

I adapted that piece of code to print the generated name:

int main(int argc, char *argv[])
{
    // qsrand(uint(std::time(0)));
    QString s(6);
    s.resize(6);
    for(int i = 0; i < 6; ++i)
    {
        char ch = char((rand() & 0xffff) % (26 + 26));
        if (ch < 26)
            s[i] = Latin1Char(ch + 'A');
        else
            s[i] = Latin1Char(ch - 26 + 'a');
    }
    qDebug() << s;

    return 0;
}

Note that the call to srand() is commented out. Running this program will produce the exact same result each time since the seed wasn't initialised properly. But that is expected. What is not expected was the following message being printed when running my simple program:

WARNING: CPU random generator seem to be failing, disable hardware random number generation
WARNING: RDRND generated: 0xffffffff 0xffffffff 0xffffffff 0xffffffff

It turns out that I have an AMD Ryzen CPU, and this warning was being emitted because of a faulty BIOS, as reported in this forum.

So I updated my BIOS to the latest version and voila, the warning is gone and the installer works again.

The reason I couldn't get it working on my second machine was because I was using a virtual machine in the same CPU. The laptop is an Intel Core CPU.

I never thought I would see a BIOS update fix some apparently unrelated program. It was a fun investigation. I would like to say thanks to @hskoglund for the patience and all the tips.

Solution:

If you have an AMD Ryzen CPU, update the BIOS.

JKSH

What a journey. Thank you for sharing your solution, @mcleary !

koahnig

@mcleary

Thanks for your effort and sharing of source.

Just for completeness

#include <QString>
#include <QDebug>

typedef ushort Char;

static inline Char Latin1Char(char ch)
{
    return ushort(uchar(ch));
}

int main(int argc, char *argv[])
{
    // qsrand(uint(std::time(0)));
    QString s(6);
    s.resize(6);
    for(int i = 0; i < 6; ++i)
    {
        char ch = char((rand() & 0xffff) % (26 + 26));
        if (ch < 26)
            s[i] = Latin1Char(ch + 'A');
        else
            s[i] = Latin1Char(ch - 26 + 'a');
    }
    qDebug() << s;

    return 0;
}

Basically one can use this as main.cpp with a QtCoreApplication template.
Tested with Qt5.14.1 for MinGW 64 bit.

JKSH

Looks like the problem (or a similar one) has been around for a while now? https://www.phoronix.com/scan.php?page=news_item&px=AMD-CPUs-RdRand-Suspend

mcleary

@JKSH It seems to be a combination of the hardware not returning random numbers and the fact that it looks like the Qt installer doesn't initialise a random seed like qsrand(uint(std::time(0))). I might be wrong since I don't have access to the actual source code.

If you take my snippet and run it on AMD with the qsrand() call rand seems to work fine.