No disk in drive G: 3.3

[cdxp]

Windows 10 x64
I have a built in empty USB card reader which shows as drive G:
If I start Qbittorrent version 3.3 it shows no disk in drive G:
If I skip or cancel the program start and it runs fine.
This didnt happen in earlier releases of Qbittorrent
Drive G: is not configured anywhere in Qbittorrent locations
I assume its now scanning for all drives before starting.

[sledgehammer999]

Are you using final v3.3.0?
A screenshot of the message would be helpful.

[kevin1979]

I've had the exact same issue and circumstances as OP immediately after upgrading to 3.3. Here's a screenshot:

http://s8.postimg.org/y5s4cnl85/Capture.png

Thanks

Edit: Also, I'm using 3.3 final, after upgrading from within the previous stable version.

[kevin1979]

To update: I went to Disk Management in Windows and changed the drive from G: to a different letter (S: in this case) and that seems to have fixed it, both immediately and after a restart. I can potentially see a lot of other people having the same issue though.

[sledgehammer999]

That is very odd. What kind of disk is G:? hdd/ssd/NAS ?
Now that you changed it to S:, is G: assigned to something else?

[SMH17]

I have the same issue. Windows 10 (v1511) x64 qBittorrent 3.3.0 final release.

[Nemo-qB]

If you remember sledge I had a very similiar issue with the RC: https://qbforums.shiki.hu/index.php/topic,3969.msg20324.html#msg20324.

The message was gone after restarting my system.

[sledgehammer999]

Maybe a qt5 issue then. Because on the RC I changed to it. I may need to perform tests in the weekend in a VM.

[bsiegel]

I'm also experiencing this issue after upgrade to 3.3. I tried clearing all my profile data and starting fresh, this did not resolve the issue. I also tried rebooting, with no effect. I ran process monitor while launching qBittorrent, but strangely did not see any attempts to access drive G: (by qbittorrent.exe, or any other process for that matter). On my machine I have a USB flash media reader that appears as drives E: through H:. The message is attached below.

[Royern]

Same issues on my pc as bsiegel above. I have a USB flash media reader that appears as drives E: through H aswell, but for some reason it want's to access G. When i click continue everything works fine it seems. I have Win 10 64 with everything updated in win update. latest builds etc.

[shanedk]

Similar error on Win7 x64. Does not go away after rebooting.

[ozgur-as]

this happens if you have a card reader in your pc. there are disk drives for card slots that are hidden by windows while there are no cards plugged in, hence the error.

disabling the card reader from device manager fixed the problem for me, although, it's not really a clean solution, qbittorrent should be able to skip the drives that do not have cards plugged in. what's the purpose of it scanning any drives during startup anyway?

[bsiegel]

I think I have determined the issue. On launch, qBittorrent is attempting to load the file G:\QBITTORRENT\install_base_msvc\ssl\openssl.cnf. It looks like qBittorrent was compiled on a machine where its source code directory was on drive G: and this absolute path somehow got compiled in to the executable.

While the file above appears to be the only one that is attempting to be loaded, for reference, here are all of the strings containing hardcoded absolute paths I found in qBittorrent.exe v3.3.0:

qt_prfxpath=G:/QBITTORRENT/install_msvc/qt5
G:\QBITTORRENT\install_base_msvc/ssl/cert.pem
G:\QBITTORRENT\install_base_msvc/ssl/certs
G:\QBITTORRENT\install_base_msvc/ssl
G:\QBITTORRENT\install_base_msvc/lib/engines
G:\QBITTORRENT\build-qbittorrent_3.3.0\src\release\qbittorrent.pdb
C:\temp\qt-user
C:\temp\qt-common
C:/tmp

Note: According to a similar bug report on the PHP bug tracker, the issue occurs because the OpenSSL library uses hardcoded paths assigned with --prefix.

There's also a workaround: Define an OPENSSL_CONF environment variable and give it a value of c:/usr/local/ssl/openssl.cnf - this will cause qBittorrent to look in that path instead of the hardcoded path on drive G:. You can do this by going to Control Panel > System > Advanced system settings > Environment Variables... > System variables > New...

[chrishirst]

Got to say that a compiler issue was a possibility that crossed my mind, but discarded immediately as being highly improbable.
Maybe I should have also thought "Well this is Windows" :)

Though it does highlight one very important problem, in that there is NOT enough testing before declaring a version as 'stable' and unleashing on the unsuspecting users.

Real testing procedures would have prevented this getting 'into the wild', just as it would have prevented the "Missing files" debacle. And real testing does not mean 'by one person' who is also a developer and/or project maintainer and 'tested' on only the one machine that is was compiled on.

The more cockups there are like this, the less confidence there will be in the project AND with everyone and anyone who is involved in the project, 'Anonymous' user names are not always as 'anonymous' as you would like to think.

[shanedk]

I do have an SD card reader that maps to G:. When I put in an SD card and restarted qBittorrent, it launched without giving me this error.

So, I can confirm that this appears to be the bug.

[Nemo-qB]

I do have a card reader also. Great find!

[shanedk]

bsiegel's workaround worked for me.

[chrishirst]

So, I can confirm that this appears to be the bug.

You don't get away that easily,

Next test is to remove the SD card, close qbittorrent, reboot the machine and restart qbittorrent without the card in place, to check if it is an initial start up 'issue' are one that occurs on every start up.

[cdxp]

I've tried on a machine with a removable USB card reader. (autoconfigures as F: G: H: I:)
card reader not plugged in no error
card in drive G: - no error
no card in drive - error
Reboot does not clear error when no card in drive

[sledgehammer999]

@bsiegel Great find! I indeed have my custom built toolchain(qt5, libtorrent, boost, openssl, zlib) in G: under that path. The very weird thing is that I had a similar setup for the v3.2.x series with qt4. It was also under G:. I don't understand why noone saw this error then....
Anyway, this weekend I'll push v3.3.1 fixing other things too. I'll have to build the new openssl version anyway, so I'll try to fix this too.

[Nemo-qB]

Great news, thanks sledge.

[mhoes]

Hi,

I have the same issue with qbittorrent 3.3 on Windows 10 Home version 1511 (build 10586.17). My G: drive is an USB slot in my printer. Turning off the printer makes the G: drive disappear, after which the issue no longer occurs. Turning the printer back on makes the G: drive appear again, and re-introduces the issue. Rebooting the PC or restarting qbittorrent does not make a difference.

[sledgehammer999]

@mhoes if only you took to the time to read a few comments above....

[mhoes]

@sledgehammer999 point taken. I did read most of the comments, just not the last ones: and thereby missing the resolution/fix will be included in v3.3.1. Thanks.

[sledgehammer999]

v3.3.1 was released. I am pretty sure it fixes this problem. Closing.

[cdxp]

Yep confirm fixed. Thank you.

[shanedk]

That fixes it for me, too. Thanks!

[shanedk]

Yep--it's back in 3.3.2!

[UncleSpellbinder]

Yep. Just updated to 3.3.2

No Disk In Drive G

[sledgehammer999]

Try fixed build: #4591 (comment)