Keep filename-casing on save about scicompanion

[Kawa-oneechan]

I can think of two ways to run SCI games: in MS-DOS (real, virtualized, or DOSBox), or through ScummVM. The former is case insensitive to begin with. The latter I don't know, because all I have to test on is Windows though I guess I could check the source, with how much abstraction that thing has.

So basically, is it worth the effort to preserve casing? And what about games with more than one volume? Would I need to remember the original casing for the entire possible range? I'm not even sure how.

[codengine]

Following scenario: Lets say I deliver a new version of the game. People that use Linux extract it and overwrite the already existing version.

If I dont take care about the filename-casing they would end up having the files twice because Linux is case-sensitive. I can't even tell you which casing has precedence in ScummVM on Linux.

I know those ancient SCI games which I'm dealing with are probably a niche market but to be honest - You cant imagine how important SCI Companion is for those translations, bugfixes etc. :)

It's not too big of a deal, but when I deliver an update and don't take care about the character casing, the situation above could occur.

[Kawa-oneechan]

You raise a good point. However, I still don't know how how to find the current casing, though I have an inkling of an idea.

Also: since they're old DOS games the "canonical" casing should be full uppercase. (Don't let Windows 95 fool you.)

Edit: FindFirstFile is case-insensitive, but returns the actual filename. Testing it by finding Resource.map returns a struct with RESOURCE.MAP in, which is what I wanted. I can use this.

[Kawa-oneechan]

If you can confirm this is what you wanted, I can extend this to include patch files as well, and close this issue.

[codengine]

Sure, extending it to patch files as well would be great! Tell me when I can download a build and test it.

[Kawa-oneechan]

A version that doesn't yet do this to patch files is already available as a Nightly release.