1

I have a small application which is a single executable. For context, this is deployed to Thin Client computers and runs automatically at boot. Users do not have the rights to close this application.

However, I need the application to be easy to update. I can't write my software to do any kind of auto-update routine, because these stations often have a write-blocker* which must be disabled beforehand.

The simplest solution as an administrator is to copy the new EXE over the old using the various tools provided with the Thin Client, or Group Policy / scripting where required. The update doesn't have to be instantly effective - the next reboot is fine.

The problem with this is that, of course, the executable is in use and can't be overwritten. What's the best way to allow this to happen? Load the software completely into memory and run from there? Do some kind of routine which copies the exe to a temporary folder and then executes it with a command line switch so it doesn't endlessly loop?

*This may have caused some confusion. These are Windows XP / Windows 7 Embedded machines. For the most part they work like normal computers, except file system writes are transparently redirected to a cache drive. On a reboot, all changes are completely reverted. A normal script to update the machine would go something like:

Disable Write Blocker 
Reboot Machine
Copy Files
Reboot Machine
Enable Write Blocker
Reboot Machine

However, my application will autostart after every reboot as there's no mechanism to inform it. As such, when the scripts get run the executable is still in use.

Dan
  • 1,958
  • 1
  • 18
  • 26
  • 3
    The only way to do this is with a "shadow copy". Files of running executables in Windows *cannot* be released as such. There are also tools to "copy [or delete] on reboot", which might be worth looking into. – user2246674 May 24 '13 at 10:15
  • @user2246674 What do you mean by a shadow copy? Do you mean using Windows VSS? If so, I can't rely on that being abled. As your for your second point, I need to make my application completely transparent in this regard. – Dan May 24 '13 at 10:20
  • 1
    There are all types of auto-update functionality for Windows software. Why not look into some of that? Don't reinvent the wheel as a trapezoid. – Cody Gray - on strike May 24 '13 at 10:21
  • @CodyGray I *can't*. These machines do not have a persistent file system. They're designed to be updated using scripts and file copies etc, so I need to find a way to work within that. – Dan May 24 '13 at 10:23
  • @Dan ..on reboot? :D (There are a number of examples found when using the phrase I dropped above.) – user2246674 May 24 '13 at 10:24
  • I'll clarify the write block issue – Dan May 24 '13 at 10:25
  • It seems to me that you have already made a lot of design decisions without considering updating. And now, when you come to think about updating, you are treating these decisions (which you took) as being hard constraints. I posit that you really should be considering updating alongside all the other design choices. I'd go right back to the drawing board if I were you. – David Heffernan May 24 '13 at 10:34
  • Is there any way to detect if write blocking is enabled? – Basic May 24 '13 at 10:35
  • I see. That wasn't in the question, or at least I didn't get it. Is "Thin Client" supposed to imply that? Anyway, how is the application getting on the machine in the first place? Do you load it during the boot phase? Why don't you just check for an *update* during the boot phase, and if there is one, fetch it. – Cody Gray - on strike May 24 '13 at 10:37
  • @DavidHeffernan Give me some clues, please? I'm trying to make this as basic as possible for the administrators. Like I say, the tools *they* have are really designed for straightforward file copies. The design decisions I've taken are based on the needs of the app, so yes, updating is now a secondary concern but I don't know what I could have done differently. – Dan May 24 '13 at 10:38
  • @CodyGray You're right, I was far from clear. One gets used to using terms with implications in a field. The application will get installed onto the machine in the same way - a simple file copy. This is fine the first time because it's not overwriting anything, it's subsequent copies where there is an issue. – Dan May 24 '13 at 10:39
  • @Basic Potentially, but it would be on a case by case and manufacturer by manufacturer basis. This would make it unmaintainable in my view. – Dan May 24 '13 at 10:40

2 Answers2

0

You might be able to use Windows' MoveFileEx with the DelayUntilReboot option.

To do this from C#, see this answer which shows how to set up the call to the Windows API.

Note: I think the call needs administrator privileges.

Community
  • 1
  • 1
shamp00
  • 11,106
  • 4
  • 38
  • 81
  • Thanks for taking the time to answer. I've clarified how the write blockers work, as I don't think this approach will work for me. – Dan May 24 '13 at 10:29
  • @Dan Why wouldn't this work? If you use this delayed move at the "Copy Files" stage in your description of the update process, the move will occur at the subsequent "Reboot Machine" step (at which point the write blocking is presumably still disabled, but prior to your app starting up since the move occurs during the boot process). – Iridium May 24 '13 at 10:43
  • @Iridium It was mostly a guess at the average process. But doing it this way would require the admin to use two mechanisms. One to prep the machines and then another to invoke an update in my application - I don't think that'd desirable. – Dan May 24 '13 at 10:50
0

You could make of use of something called Shadow copying assemblies. Search the net, you'll find lots of examples (also on SO and Codeproject).

Obviously the application can only update if your write protection is disabled. Are you using FBWF or EWF? You might even exclude the application folder from write protection.

JeffRSon
  • 10,404
  • 4
  • 26
  • 51