none
Can't override file in \windows programmatically SECOND time RRS feed

  • Question

  • Hello,

    I have simple issue but can't find the solution (windows CE 6.0).

    I have xxx.dll in \windows directory. This dll is part of OS image ("rom mapped" part). I "overrided" this dll by new dll with the same name xxx.dll. I simply copy this new dll into \windows directory using RAPI. After that I can see new xxx.dll in \windows directory. I understand that old.dll is really situated in rom memory and only mapped on \windows. After I "overrided" this dll by new dll with the same name the OS is using new dll from \windows. When I delete this "new dll" I can see in \windows "old dll" again. So the all look fine.

    But there is next obscure for me behaviour of Windows CE 6.0:

    1. When I try after reset overwrite this "new dll" by another "new dll" with the same name - I can't do it anymore!!! Looks like I can override old dll (rom mapped dll) ONLY ONE TIME! Why???

    Note that when I delete "new dll" from \windows directory I see old xxx.dll (rom mapped dll). Only after that I can override this dll with another dll with the same name! Looks like after first "override" old dll - new dll becomes not overriden! Why?

    So my questions:

    1. Why is it occur?

    2. How solve this situation when I want programmatically override xxx.dll second time (overwrite new xxx.dll by another new xxx.dll)?

    I tried at first programmatically delete new xxx.dll from \windows and then override old dll (which appears again) second time. But the problem is that I can't delete new dll programmatically! I tried use CeDeleteFile, DeleteFile - all without success. I can delete it only from explorer handly!

    I quess that maybe I can delete it using CMD but the problem is that CMD isn't exist in image and I don't want update image to include that.

    Please give me any programmatically solution you know!

    Thanks for any help!

    Friday, March 22, 2013 11:20 AM

Answers

  • I think that makes sense - not in a I would have thought to do it that way makes sense, but in a that is how the system works makes sense.

    The first time isn't really replacing the file, as in delete and add new, it is just pointing at a new file.   The second time is actually replacing the file.

    Since the it is a real file the second time, it fails.

    The following work around may work for you.  On the second time, and may even work the first time:

    1. rename the file in the \Windows folder

    2. Copy new file to \Windows folder

    3. Delete renamed file - you may not be able to do this until after a reboot


    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    • Marked as answer by Jacviah Tuesday, March 26, 2013 6:12 PM
    Monday, March 25, 2013 1:18 PM
    Moderator

All replies

  • If you call GetLastError() after the DeleteFile that fails, what do you get?  Maybe your new DLL has a readonly attribute, or your DLL is under utilization.

    Friday, March 22, 2013 2:44 PM
  • No, DLL hasn't readonly attribute, I see that the dll is occupied by some process, I can see that this process is NK.exe.

    However I see from process viewer that NK.exe always occupies this dll. But I have the problem ONLY during SECOND override.

    Thanks for reply!

    Monday, March 25, 2013 10:48 AM
  • I think that makes sense - not in a I would have thought to do it that way makes sense, but in a that is how the system works makes sense.

    The first time isn't really replacing the file, as in delete and add new, it is just pointing at a new file.   The second time is actually replacing the file.

    Since the it is a real file the second time, it fails.

    The following work around may work for you.  On the second time, and may even work the first time:

    1. rename the file in the \Windows folder

    2. Copy new file to \Windows folder

    3. Delete renamed file - you may not be able to do this until after a reboot


    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG http://geekswithblogs.net/bruceeitman

    Eurotech Inc.
    www.Eurotech.com

    • Marked as answer by Jacviah Tuesday, March 26, 2013 6:12 PM
    Monday, March 25, 2013 1:18 PM
    Moderator
  • Bruce, thanks for reply. I just discovered the possibility rename DLL and then copy new version!

    But this behaviour of the system looks very strange... I understand that image's "mapped" version of DLL and "real" DLL file (that I copy) - are two different cases. My understanding even can accept the situation when I can't overwrite/delete "real" DLL after I copied that into \windows. But why I can rename that? In case the system locks the access to "real" DLL after I overrided "mapped" version by it - why I can rename that and why I can delete it after restart?

    The other important for me question - why I can delete "real" version of DLL (copied into \windows first time) using Explorer, but I can't make that using DeleteFile or CeDeleteFile api?

    In general, how does WinCE process the operations (copy/delete/overwrite/override) for \windows?

    Monday, March 25, 2013 5:48 PM