Cura: Having removed removeable device since cura was last opened causes repeating pop-up error messages.

[dintid]

Issue and steps:

1) Use Cura and have a removeable device inserted, like a SD card, with associated drive letter.
2) Close Cura and unplug device.
3) Open Cura and it repeatedly starts complaining about missing drive.

[Ghostkeeper]

Doesn't occur on Ubuntu 15.04. Can someone try to reproduce on Windows?

[dintid]

It's doing it on both my PC and Laptop. Having Win10 x64 all updates on both.

Edit: I have had this issue a lot, and it was annoying, but now when I want to take a screenshot it doesn't happen.. will do some more methodical testing again.

[Ghostkeeper]

I believe you :stuck_out_tongue: We do need to reproduce it to be able to debug anything though.

[dintid]

I know :) and I reproduced it now.

Case and steps:
1) Inserts cardreader which gets assigned letter D: on my PC.
2) Insert SD and drive is now ready - It doesn't matter wheter SD is inserted at step 1 or not...
3) Use Cura 2.3 to slize something and save to Removeable Drive letter D:
4) Remove SD and Close Cura - order not important.
5) Let cardreader stay in PC but without SD card.
6) Open Cura and slize something
7) When hitting "Save to File" in Cura, you get pop-up error that drive D: is not available, and it keeps nagging for a while.

Transaltion of image from Danish:
Header: Cura.exe - No disc (really it says no floppy inserted)
Main text: There is no floppy inserted in the drive. Insert a floppy disc into drive D:
Buttons: Cancel - Try again - Continue

[Ghostkeeper]

I wonder how other applications react if they try to write to a drive that doesn't exist any more even though Windows tells them it does...

[dintid]

Microsoft programs like Office uses last saved folder, but if it doesn't exist anymore it's going to the user's folder.. if that one is unavailable it reverts to "My computer" instead of throwing errors.

Since Cura acts differently it seems like this could be a programmed behaviour for the Office suites.

[Ghostkeeper]

Ah, so even though the drive letter still exists, we might prevent saving to the removed SD card by checking if the folder still exists.

[nanospork]

Just wanted to add that I also am running into this issue, Windows 10, Cura 2.5.

I can't even get Cura to start because this message pops up, and regardless of whether I hit "Cancel" "Try Again" or "Continue" it just pops up again, Cura never actually finishes loading. I have to open Task Manager and kill it manually just to get the thing to go away.

Also note that I never had anything inserted in Drive D: in the first place, but that's the drive it's apparently looking for...

edit: Steps to reproduce:

1. Install Cura 2.5
2. Download MicrosoftStore's Space Shuttle: http://www.thingiverse.com/thing:413696
3. Open shuttle.stl in Cura.
4. Click on the "Support" tab.
5. Cura crashes.
6. Try opening Cura again, get the never-ending pop-up. Only way out of it seems to be re-installing.

[dintid]

If I unpluck my cardreader cura stops popping the errors. I know this is not a solution if your cardreader is build in though.

[nanospork]

I managed to bypass it by disabling "removable drive D:". I don't think it was actually being used by my card reader, I think it was unassigned before installing Cura but I could be misremembering.

Not an ideal fix but it lets me print anyway.

[Ghostkeeper]

The thing is that Windows tells Cura that a removable drive is available there. But when Cura tries to access it, Windows shows the user an error that the drive is not there.

I hope that Cura receives a PermissionError from Windows to indicate that the read isn't possible. Perhaps you could share a log file of Cura, to see why it was trying to save to that D drive?

[billvinson]

I've been using Cura 2.5 for a week or 2 (loading & exiting over that time) without issue until I tried double-clicking on an STL to open Cura and now I see these messages. I never use my D drive (DVD-ROM) but I'd prefer to to have to change it's drive letter long-term to work around this bug...

[nallath]

This is fixed for the next release (2.7)

[fieldOfView]

What wad the solution? I can't find a commit for the fix

[awhiemstra]

https://github.com/Ultimaker/Cura/commit/ef51897b716ecb42aedef12932f9df2e965f3f5e

Basically, the fix was to tell Windows to shut up and not show error dialogs...

[nallath]

Funny thing; default behaviour was different for 32 bit then it was for 64.

[h3tr1ck]

@nallath Can you please let me know how this issue was fixed. I just installed Cura 2.7 on a clean install of Windows 10 64bit and was met with the endless pop up messages.

[fieldOfView]

@h3tr1ck as you found out, it was only partially fixed. The devs are hoping they can fix it for real for the next release,

[Ghostkeeper]

Next release we'll be trying a different partial solution: Change the drive letter of the build server to X:, because that letter isn't used very often...

[fieldOfView]

How about symlinking it to somewhere on C:? A "file not found" does not result in an issue, only an empty removable drive.

[Urs-O]

@Ghostkeeper Better change it to a letter in between, the end of the alphabet is often used for network drives - I have just run into that bug too and at least we at university have those letters for network drives...

[Ghostkeeper]

Turns out that everyone has different ideas of what frequently-used drive letters are. Myself I've often seen M and N for network drives, W for web, etc. I got advised on Z but that's also used by software apparently.

But what really matters is faulty drives. Network drives are often working sort of correctly, as in, they don't pretend you can write to it. I agree that C could solve a lot of problems but it could also give some unforeseen problems in our build system. I don't know, but X is what Nallath, Awhiemstra and I arrived on.

[Urs-O]

I wanted to point to the root of the evil: Why using a drive letter to ask for? And why react with a window that can´t be clicked away?

[fieldOfView]

Why using a drive letter to ask for?

It is an artifact of the buildsystem that has so far been impossible to circumvent

And why react with a window that can´t be clicked away?

That's a reaction by Windows to the abovementioned artifact in the buildsystem that is outside of the control of Cura.

[nallath]

We just can't seem to find why the hell it wants to have a hardcoded path and why it only wants it for a specific set of imports.

[nicolinux]

Hey guys, this issue is not fixed, there are reports of this error with Cura 2.7.

[fieldOfView]

That is both correct and incorrect.
It is fixed, but after the 2.7 release.

[nicolinux]

Ok, thanks for the info - so we need to communicate it better next time. I hate to see when users are frustrated about these bugs even though they were fixed "a long time ago".