kernel32: Fix for WritePrivateProfileString Sharing Problem [2/2]

[Erich Hoover]

On Fri, Feb 29, 2008 at 1:18 AM, James Hawkins <truiken at gmail.com> wrote:
>
> On Fri, Feb 29, 2008 at 1:17 AM, Erich Hoover <ehoover at mines.edu> wrote:
>  >
>  > On Thu, Feb 28, 2008 at 11:44 PM, James Hawkins <truiken at gmail.com> wrote:
>  >  >
>  >  > On Fri, Feb 29, 2008 at 12:29 AM, Erich Hoover <ehoover at mines.edu> wrote:
>  >  >  > Patch Originally From:
>  >  >  >    Louis Lenders
>  >  >  > Description:
>  >  >  >    This patch adds conformance tests for WritePrivateProfileString sharing
>  >  >  > problems.  The patch was created by Louis Lenders and extensively tested,
>  >  >  > but never submitted (see Bug #5024).  Please note that a couple of the tests
>  >  >  > now fail because cached profile information is returned, resolving that
>  >  >  > problem is outside the scope of these patches.
>  >  >  >  Changelog:
>  >  >  >    kernel32: Test for WritePrivateProfileString Sharing Permissions
>  >  >  >
>  >  >
>  >  >  If a test fails, it has to be wrapped in todo_wine, else make test will fail.
>  >  >
>  >  >  --
>  >  >  James Hawkins
>  >  >
>  >
>  >  I would argue that make test should fail for regressions, though I
>  >  don't know when exactly this particular problem surfaced.  Re-ording
>  >  the tests can actually mask the problem as well as inserting
>  >  todo_wine, which would be preferred?
>  >
>
>  Um make test does fail for regressions.  make test fails if an ok call
>  fails and is not covered by todo_wine, and it also fails when a test
>  in a todo_wine block succeeds.  That's how we keep track of the tests.
>   If reordering the tests masks the problem, what's the point of the
>  tests?
>
>  --
>  James Hawkins
>

The tests are for checking the sharing permissions problem, which
causes WritePrivateProfileString to fail when the profile file is
opened by CreateFile before WritePrivateProfileString is called.  The
tests failing now is a result of a problem with wine caching the
profile information from when the call previously succeeded (the cache
is not updated properly when the file is deleted).  What I'm trying to
say is that the tests are currently exposing a separate issue, so a
separate set of tests would probably be appropriate - problems with
caching are outside the scope of the patches I submitted.

Erich Hoover
ehoover at mines.edu