none
Exclusively locking a file RRS feed

  • Question

  • Hello,

    I have a requirement to lock a file which gets streamed into the support directory. The lock should be established for the duration of the install. Just before the files are cleaned up, the lock should be released. The purpose of the lock is to ensure that the file is not tampered with for the duration of the install.

    To accomplish the same, i wrote a custom action . My goal is that the file lock should be established right after it gets extracted to the support directory.

    The custom action is being used from a C++ dll. When i launch the installer, the custom action locks the file for a split second and then as soon as the welcome dialog is displayed, the lock is lost.

    I am aware that there are 3 msiexec processes running simultaneously. The msiexec process which hosts the custom actions is still active.

    What could be the possible reason?
    How can i accomplish what i want to do? Any ideas?

    My project is a windows installer based project

    Wednesday, November 11, 2009 7:56 AM

All replies

  • Hi Kiran,

    Since I don't know when you CA was invoked, is it sync or async, what's the code like in the CA; I'm not sure what happened in your CA.

    However, I believe you can use the Process Monitor tool to see at what time the file was locked/unlocked, you can also get the call stack of the event. That will help you a lot debugging the CA. Just set the filter as Process Name = msiexec.exe and Path contains <your filename to be locked>, so you can filter out most irrelevant events.

    Hope this helps.

    Regards,
    Jie
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    If you have any feedback, please tell us.

    The CodeFx Project
    My Blog (in Simplified Chinese)
    Wednesday, November 11, 2009 12:14 PM
  • My custom action was inserted  in the User Interface sequence. It is a synchronous,immediate mode custom action.
    The C++ code used is as follows:

    DWORD LockOrUnlockFile(FILE *fp,BOOL bLock,LPCTSTR lpFileName,LPCTSTR FileOpenMode)

    {

     

     

    if(bLock)

    {

    fp = NULL;

    errno_t err;

    err = _tfopen_s(&fp,lpFileName,FileOpenMode);

     

    if (err != 0)

    {

     

    return err;

    }

    _lock_file(fp);

    }

     

     

    if(!bLock)

    {

     

    _unlock_file(fp);

    fclose(fp);

    }

     

     

    return ERROR_SUCCESS;

    }


    The file pointer is a global file pointer, since i would like to unlock the file before it is deleted from the support files directory.

    I have monitored the activity using process explorer and have observed that the file gets locked when the custom action is launched. However as soon as the UI(welcome screen) is displayed, the file is unlocked.

    BTW, how do i get the call stack?(From Visual studio)

     

    Wednesday, November 11, 2009 12:23 PM
  • We use Process Monitor, not Explorer to get the call stack.

    Double click the event item you're interested in (like Close File) and in the property dialog you'll find a call stack tab.

    Regards,
    Jie
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    If you have any feedback, please tell us.

    The CodeFx Project
    My Blog (in Simplified Chinese)
    Wednesday, November 11, 2009 12:29 PM
  • What's the underlying problem you're trying to solve here? And who is doing this streaming of the file?

    I'm asking because Windows Installer isn't going to tamper with any files during the install. If your setup is installing a new version of this file and it's in use at the time then the install won't just get rid of it. If it's attached to an app with a window then Windows will show a files in use dialog asking you to shut down the app. Otherwise it will get to the end and prompt for a reboot so it can replace the file after a reboot.

    (Note also that there is no mechanism (like a custom action) that you can use in VS to lock a file "for the duration of the install" because custom actions run after all the files are installed and it's essentially finished. )

    So I'm wondering if you're trying to solve a problem that doesn't exist.  What problem do you believe that locking the file will solve?


    Phil Wilson
    Wednesday, November 11, 2009 8:20 PM
    Moderator
  • The installer is streaming this file into a support directory.
    So the problem that i trying to resolve is something like this:

    We have some secure information which needs to be imported into our database. The secure information is security  keys which would be used for secure communication in our product. These keys are in a file which needs to be secured before it is imported into our database. We do not want anyone to tamper with the information in the files as soon as it lands on the disk. During the installation, a utility will read this file and update our database. So i want a mechanism by which i could lock the file for exclusive access, so that the secure information is not tampered with.


    BTW, once the keys are updated in our database, the key file will be deleted from the support directory. We are not going to install this file with our product.

    And the custom action i have sequenced is in the UI phase.

    Am i clear now?
    Thursday, November 12, 2009 6:04 AM
  • Is this a Visual Studio setup project? It doesn't sound like it because you can't have custom actions in the UI sequence unless you change the MSI file afterwards. 

    Files aren't installed when the Welcome dialog is shown, so there's nothing to lock. First there's a UI sequence to collect data, after which the execute sequence (progress bar etc) installs the actual file. Unless you're doing something odd, there is no file on the system for you to lock until the end of the execute sequence. So there's a timing issue here too because either you've got a strange install that has the file in the support directory before the install's Welcome dialog or you've got a misunderstanding about when things actually happen during an install, because nothing is ever on disk before the Welcome dialog is shown.
    If the file is installed by the MSI because it's actually in the MSI (in the file table and you're not creating it) then removing it afterwards won't work. A right-click repair on the MSI file will restore it. It's also true that the msiexec /a command ("administrative install") can be used at anytime to create an administrative image of all the files in the install, and anyone can go look at it, in case that's an issue because the content is supposed to be secret.

    I don't think this is an install issue really, although you're making it into one. If the file content is supposed to be untamperable (and maybe secret) then encrypt it with a real encryption algorithm before you install it, then at least it's more secure and how could anyone understand the content to do any meaningful changess?  Also, don't install it at all. Embed it in the resources of an installed executable (maybe the same executable that updates the db) and read it from there (where it can also be encrypted).
    Phil Wilson
    Thursday, November 12, 2009 6:44 PM
    Moderator
  • Well it's a msi installer and the authoring tool used is from Installshield.
    I am not saying that the  file i want to lock  will eventually get installed. The file i want to lock is streamed into a temporary directory which eventually gets cleaned up after an install. So the streaming of this file happens just before the welcome panel is displayed.


    There is a utility which gets installed with our product, which would then read this file from the support directory and update our database.

    BTW, i did an administrative install and discovered that the support files do not get extracted.
    Friday, November 13, 2009 12:40 PM
  • The difficulty is that this a forum for Visual Studio setup projects, so everyone is trying to answer your question in terms of what VS setups do, where people don't store files in the binary table and can't run custom actions anywhere except after all the files have been installed. Unless you tell us this, we don't know what's going on, so yes, a file in the binary table isn't installed with a /a install.
    In any case, without knowing all the details it's still hard to answer. If the file is actually streamed out before the Welcome dialog then that seems way too early for an update that is done after files are installed - no wonder there's a time gap. 

    I still think the decision to store this in the binary table is what causes the security problem, and my take on that is that instead of wondering if you can lock the file for some period of time, just don't do it. Store the data in the resources of some exe or Dll and get it from there. That's a stoage that is readonly by definition.
    I'm also not sure why locking the file can be a solution. Apart from the fact that _lock_file actually locks a critical section and not the file, whatever you do will be for the duration of the custom action call, not for the duration of the install. Custom actions don't run for the duration of the install.

    Phil Wilson
    Friday, November 13, 2009 6:49 PM
    Moderator