On Tue, 2012-06-19 at 20:55 +0200, robert.van.herk@serioustoys.com wrote:
Yes, the concern is that the file could be changed or removed. We should test what native does here but it probably means that we need to create a stream on the file with a sharing mode that denies writing.
So... I tried this out. I do not understand what I found though!
On Windows, after MSI_RecordSetStreamFromFileW, you CAN call DeleteFile on that file. But you cannot open the file for writing; that will give ERROR_ACCESS_DENIED.
I found in the specs of DeleteFile that this behaviour is understandable, because " The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. "
On the other hand, it says: " The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. "
So... I figured that somehow in the MS implementation of RecordSetStreamFromFile they called SHCreateStreamOnFileEx with parameters that allowed it to be scheduled for deletion through DeleteFile, and didn't allow the file to be opened again for writing.
So far so good.
So I set out to find this combination of parameters and I cannot find it. I saw that for CreateFile, you can pass FILE_SHARE_DELETE, and I guess that that allows for DeleteFile to be called. However, you cannot pass flags to SHCreateStreamOnFileEx that will cause this flag to be set...
We don't have to call SHCreateStreamOnFileEx, we can add a suitable implementation to msi.