QGIS saves files to CWD by default when only a filename is entered, but CWD is not sane on Windows

[AlisterH]

(Apologies if there is an open ticket for this, I can't find any, or any with "won't fix" type comments. I know there have been many over the years, e.g. #18221, with the insight "it makes no sense to ever put data into /bin").

Various dialogs in QGIS (such as the layer save-as dialog) require an output file to be specified, providing a button to open a file selector, together with a text field where a filepath or just a file name can be typed or pasted.

If the user enters just a filename instead of a full path, QGIS tries to save it in the current working directory. On a proper operating system like Linux this is normal, so I guess it makes sense. But on Windows it is very strange and unhelpful, and we might be surprised how often people do it and then can't figure out where their files went.

If the user doesn't have the necessary permissions (likely if they used the standalone Windows installer), they get a message like this: "Export to vector file failed. Error: Creation of layer failed (OGR error: Failed to create file testfff.shp: Permission denied)". They will be baffled but should be able to try again and figure out how to get their file saved.

If the user does have the necessary permissions (likely if they used the Osgeo4w installer) their file is successfully saved buried in the QGIS program folder, but the user will have no idea that is where they can find it, and even if the file was added to the project, they can't actually find out where it is by looking at the layer properties, or by clicking the hyperlink in the layer properties or the hyperlink in the message bar (neither will work). (This is #18222, which was perplexingly closed with a note about 2.x end-of-life).

If I look at my "Current environment variables" in the QGIS settings, HOME seems to be set sensibly, and is bold, indicating it was modified at startup (because it isn't a standard variable in Windows). I haven't checked how or why it is set at startup, but if you're willing to mess with something like that, it might be worth introducing a setting or environment variable to provide a sane default working directory, or to enable something like "save files to HOME by default".

Workaround: The behaviour can be improved somewhat by using a startup script (on Windows typically %AppData%\QGIS\QGIS3\startup.py) containing something like this, but of course a workaround is only useful once you know what's going on:

import os

# set the working directory at startup (otherwise it defaults to the bin location)
os.chdir(os.environ['HOME'])

[gioman]

which was perplexingly closed with a note about 2.x end-of-life

@AlisterH there is nothing to e perplexed. In advance of moving from Redmine to GH issue tracker we needed to cleanup things. Original issuers had always the option to ask to reopen the issue if it was still valid. If a valid issue was closed this way and if it is important then is likely to have been filed again...

[roya0045]

Instead of the current working directory the project directory might be a better option for all cases. I feel like this should't too hard to do if someone wants to fix this.

[AlisterH]

You would still have essentially the same problem, because where is the default "project directory"? A lot of the time people open QGIS, drag in a bunch of layers and do stuff, before they have saved the project.

[AlisterH]

You would still have essentially the same problem, because where is the default "project directory"?

Also, I had an idea projects could be saved in a database, or someone had plans to implement this.

To me it seems simplest to change the working directory at startup, just like the workaround. I'm just not sure whether it is best done through the settings system, or by creating a default startup.py

If it was done with a setting, I guess linux users wanting it to work in the normal way could achieve that by setting it to "./"

[roya0045]

I know that I fiddled with the current directory in my changes to the auto-finder for the bad layer handler. I'm not sure if this has an effect in the situation that you described.

[roya0045]

somehow it seems to reach this line https://github.com/qgis/QGIS/blob/b00d6fa61a7a0fa9e664a85e654756eaa071fe34/src/gui/qgsfilewidget.cpp#L298 judging by behaviour, would have to validate with debug.

[drf5n]

CWD is not sane on MacOS either, per https://github.com/qgis/QGIS/issues/39975#issuecomment-725840125

On MacOS, CWD could be the un-writable root directory / in some cases, causing file creation errors, or with a fresh profile, it could be the installation directory /Applications/QGIS.app/Contents/MacOS/ which is writable, but not normally discoverable with normal MacOS search tools such as Spotlight or Finder.

The non-writable versus writable CWD difference could cause confusing problems in repeatable debugging or confirmation, since the bug reporting process recommends using a fresh profile, which chooses a writable, common CWD.

I found a workaround that seems to stabilize QGIS quite a bit on Mac--I set the working directory to $HOME by default with this code in my /Users/drf/Library/Application\ Support/QGIS/QGIS3/startup.py:

import os

# set the working directory at startup (otherwise it defaults to the bin location)
os.chdir(os.environ['HOME'])

[kgjenkins]

I just helped someone troubleshoot exporting selected features on a Mac -- the problem was that QGIS was trying to save to / for which it had no permissions. The error message said:

Error: Creation of data source failed (OGR error: sqlite3_open(test.gpkg) failed: unable to open database file)

That error seems a bit cryptic to many users, since it is not explicitly saying it is a permissions issue. It would be great if QGIS could test permissions when writing files (maybe using Python's os.access()?) and give a more helpful error message.

[drf5n]

That error seems a bit cryptic to many users, since it is not explicitly saying it is a permissions issue. It would be great if QGIS could test permissions when writing files (maybe using Python's os.access()?) and give a more helpful error message.

It can be extra cryptic when chasing it down on a Mac because the unspecified current working directory can be unwritable (/) or not (/Applications/QGIS.app/Contents/MacOS/) depending on how the environment was created.