On Tue, 2012-06-19 at 20:55 +0200, robert.van.h...@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.
