Using --configdir doesn't prevent the creation of the default directory

[wzdev-ci]

resolution_fixed type_bug | by DylanDog

---

I use to play and test mods from USB stick and to do this my shortcut looks like the following: "F:\Warzone2100\WZ.exe --configdir "F:\Warzone2100" --datadir "F:\Warzone2100" --window --mod_ca HM_AlphaCampaign.wz". The game starts form USB,and the games are also saved there, no problem. The issue I see is that a folder "Warzone 2100 2.3" is created anyway on the pc. This should not be the case. I do not like having this folder created on my pc at work...

---

Issue migrated from trac:2116 at 2022-04-16 06:33:38 -0700

[wzdev-ci]

Buginator changed status from new to pending

[wzdev-ci]

Buginator commented

---

What version is this ?

If you specify a configdir, then it will use that, and not "Warzone 2100 2.3"...

With svn/2.3, I have it e:\wz\warzone2100-dbg.exe --configdir .\ --window and it works as it should.

[wzdev-ci]

DylanDog commented

---

The version is 2.3.X all of them. The system is windows XP.

It is not working. I use "F:\Warzone2100\WZ.exe --configdir .\ --window --mod HM_AlphaCampaign.wz" and the folder "Warzone 2100 2.3" is created under the "My data" (In German -> Eigene Datei) anyway.

The sub-folder "Warzone 2100 2.3\logs" is also create but NOT USED.

I mean the log data and the saved games are all on the USB stick as it should but the folder on the PC is created anyway.

[wzdev-ci]

i-NoD commented

---

AFAIK its due to
this code. I was wondering why trunk is always creating 2.3 folder in my docs, so here is the answer. I've locally fixed it for trunk and forgot, lol. But you've reminded me of that "feature".

[wzdev-ci]

Buginator commented

---

Replying to Warzone2100/old-trac-import#2116 (comment:3):

AFAIK its due to
this code. I was wondering why trunk is always creating 2.3 folder in my docs, so here is the answer. I've locally fixed it for trunk and forgot, lol. But you've reminded me of that "feature".

You got the patch handy i-NoD ?

Nice to see you again :)

[wzdev-ci]

i-NoD commented

---

Hi Buginator,

Nope, no patch for THIS problem, my 'fix' was for trunk 'Warzone 2100 2.3/logs' -> 'Warzone 2100 Trunk/logs'.

This problem is a bit trickier, since log dir is created before the cmd line args are parsed in code... hmm, i don't really like it... but maybe we could use some global var to postpone creation till the moment of first actual use. Still if smth fatal will happen (i guess a lot can happen there) before arg-parser will be invoked then exception handler will simply puke from UAC protection, right? There should be some other way...

[wzdev-ci]

dak180 changed status from pending to closed

[wzdev-ci]

dak180 changed resolution from `` to needinfo

[wzdev-ci]

dak180 commented

---

Pending is broken so set tickets to something else.

[wzdev-ci]

dak180 changed status from closed to reopened

[wzdev-ci]

dak180 changed resolution from needinfo to ``

[wzdev-ci]

cybersphinx changed status from reopened to closed

[wzdev-ci]

cybersphinx changed resolution from `` to fixed

[wzdev-ci]

cybersphinx commented

---

Should be fixed in 5506daef71feb4e3c513b2a35788da5b4858af61.

[wzdev-ci]

cybersphinx changed resolution from fixed to ``

[wzdev-ci]

cybersphinx changed status from closed to reopened

[wzdev-ci]

cybersphinx commented

---

... or not, actually. Why do we use WZ_WRITEDIR for more than as default configdir anyway? Just move parseCommandLineEarly before setupExceptionHandler, and use configdir everywhere.

[wzdev-ci]

vexed commented

---

configdir works just fine, I use it all the time. Haven't tested datadir, but I thought it worked before...

It is bad mojo to do anything before setting up the exception handler, that was why it was written like that, so it is still possible we crash before parseCommandLineEarly.

[wzdev-ci]

cybersphinx changed title from datadir/configdir command lines not working properly to Using --configdir doesn't prevent the creation of the default directory

[wzdev-ci]

cybersphinx commented

---

Don't remember any crashes in parseCommandLineEarly, so I don't see the problem in doing that before setting up the exception handler.

[wzdev-ci]

vexed changed status from reopened to closed

[wzdev-ci]

vexed changed resolution from `` to fixed

[wzdev-ci]

vexed commented

---

It was re-written to not write outside your config dir.