[Bug 37850] New: fallout 2: problem with handling file permissions ?

https://bugs.winehq.org/show_bug.cgi?id=37850

Bug ID: 37850
           Summary: fallout 2: problem with handling file permissions ?
           Product: Wine
           Version: 1.7.33
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

There seems to be an odd quirk in falout 2 when running it under wine.

It's documented on falloutmods.wikia.com/wiki/F2RP_Technical_Info.
I've tested it with unofficial 1.02.31 patch, which is F2RP stripped down to
bugfixes and graphic upgrade only (from the same author). It's actually
semi-official, as (AFAIK) GOG version uses an older version of that patch.

The exact steps were:
1. install fallout 2
2. get the *manual* version of the patch
3. read the instruction of the patch and strip them down as much as possible:
- copy the patch files and apply master.dat patch
- copy only the executable and ddraw.dll wrapper lib (from Win7 set), setup
native override for that wrapper, set 'Mode=4' in ddraw.ini
- get native d3dcompiler_43.dll (due to unimplemented fx_2_0 effect) and
d3dx9_36.dll (due to an error with a message, that doesn't say anything
meaningful)

Now, after that you should be able to start the game, but if you try to save
it, you'll run into the mentioned quirk. While most of the instructions on the
mentioned site seem a bit out of date, the one specific bit is still required,
even though it doesn't make much sense and is obviously irrelevant on Windows.

Now, as you try to save, the game will return "unable to save" dialog and no
*valid* savegame will be created, even though quite a few files in the save dir
will.

This problem is fixed by the snippet mentioned on that site:
chmod 444 [dD]ata/[pP]roto/[iI]tems/* [dD]ata/[pP]roto/[cC]ritters/*

Which actually stands for 'chmod a-w ...'

Afterwards, saving works as expected.

Now, as Windows obviously doesn't need anything alike, why does wine ?
Even if that's caused by some hacky solution in the original executable, this
would suggest something being subtly broken in some quite low level wine
function (at least that's what it seems to me).