On 22/06/2012 7:23 PM, robert.van.h...@serioustoys.com wrote:
>>> Is there any reason that you call DeleteFile() on a still being opened file?
>>
>> That's the whole point of this test. The observed behavior is that you can
>> pass a
>> filename to MsiRecordSetStream, successfully delete the file,
> > Is there any reason that you call DeleteFile() on a still being opened file?
>
> That's the whole point of this test. The observed behavior is that you can
> pass a
> filename to MsiRecordSetStream, successfully delete the file, and keep on
> using the
> stream.
I think DeleteFile on a opene
On 21/06/2012 7:11 PM, Dmitry Timoshkov wrote:
> Hans Leidekker wrote:
>
>>> Is there any reason that you call DeleteFile() on a still being opened file?
>>
>> That's the whole point of this test. The observed behavior is that you can
>> pass a
>> filename to MsiRecordSetStream, successfully del
Hans Leidekker wrote:
> > Is there any reason that you call DeleteFile() on a still being opened file?
>
> That's the whole point of this test. The observed behavior is that you can
> pass a
> filename to MsiRecordSetStream, successfully delete the file, and keep on
> using the
> stream.
>
>
On Thu, 2012-06-21 at 16:03 +0900, Dmitry Timoshkov wrote:
> > Shall I file a bug report?
>
> Try to add a test case to dlls/kenel32/tests/file.c,test_file_sharing().
>
> > HANDLE h2 = CreateFileA(filename, GENERIC_READ, FILE_SHARE_DELETE |
> > FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0);
> >
"robert.van.h...@serioustoys.com" wrote:
> I feel hesitation towards starting to hack in kernel32 myself. Though this
> bug seems to be blocking me to implement msi.dll completely compatible with
> the MS implementation...
You shouldn't look how native msi.dll behaves internally.
> Shall I file
