> 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... I am a bit out of ideas now... Maybe SHCreateStreamOnFileEx does NOT actually create the stream, but just opens the file and stores the filename in order to create the stream later on, when it is needed? Thus, some sort of lazy initialization? Any other ideas? Regards, Robert
