clean_temp: not safe for concurrent use

[hamish]

if you do $ grass65 -gui you will see that it prints "Cleaning up temporary files ..." from init.sh line # 415 devbr6). i.e. before the interactive startup.

But the new LOCATION_NAME and MAPSET are not really finalized until after about line 711.

So it's a bummer if you startup another session of GRASS while you have some process running in the first (good chance the first is the mapset stored in .grassrc6) which is using temp files. Init.bat has similar issues, and I would guess that windows isn't as forgiving when you attempt to delete open files.

if it's a shell script running there's no guarantee that the file will be kept open between when it's written and when it's needed. could be a real pain for long running process to have .tmp disappear mid calculation.

Hamish

[wenzeslaus]

This still might be an issue. clean_temp() (which calls clean_temp) is called on line 2040​ while mapset is set and ready later on line 2087​. Same in 7.0 and trunk (7.7). (Now I have second thoughts about closing #1286, but if it is an issue (location being set, but possibly garbage), it is really this one anyway.)

[wenzeslaus]

My current understanding is that that clean_temp is called in grass.py right when it checks if it determines that it is not a new user which is taken as a reason to clean the current mapset. Unfortunately the current mapset is the last used mapset, not necessarily the one requested. The mapset locking happens later on and only after that we can clean the mapset. Therefore, I will move the clean_temp call only after the lock.

Note: There is another clean_temp at the end. My assumption is that the start time one is meant to clean the mapset just in case.

[wenzeslaus]

In 73342:

init: clean mapset only after locking it (fixes #613, see #1286)

Only after we set the user-requested mapset as current (GISRC) and lock it,
we can do the startup cleaning using clean_temp (to clean after previous sessions
if needed).

The cleaning was in place at least since r11260 but it got moved to a wrong place some
time after that but before r37863.

[hamish]

Replying to wenzeslaus:

Note: There is another clean_temp at the end. My assumption is that the start time one is meant to clean the mapset just in case.

Yes exactly right, as the previous session may have ended uncleanly with a crash/kill/reboot.

best, Hamish