akotti

Writing a script has always been simpler than making a proper installer, because you need to adhere to various transactional rules, implement a proper rollback mechanism, worry about making your components have correct keys that still work after an upgrade. And e.g. if you need to install a Windows service, most of the standard options (even those provided by Wix) don't cover all cases out of the box. So to some extent using a script means replacing a more complex, but complete solution with an ad-hoc thing that may work in general, but fails a lot of corner cases.

Having an AIO installer is a nice thing. On Windows, the Microsoft recommended way is the install-docker-ce.ps1 script without an ability to do an actual upgrade other than with full uninstall/reinstall.

Our management console (the client) is integrated into MMC, so it's limited to running under .NET Framework. While e.g. StreamJsonRpc can be used in this environment, it would also result in an awful amount of dependencies (Nerdbank.Streams, Microsoft.VisualStudio.Validation, Nerdbank.Streams, MessagePack, etc.), all of which are kind of tricky to bundle.

So we decided that in the long run, a simple custom IPC implementation would actually be more maintainable.

As far as I remember, in that case you still will be able to get a directory handle (with appropriate permissions), but calling FlushFileBuffers() on it is going to fail.

So you can test for that in advance before the restore and switch to syncing each file individually. Or accept that the approach only works locally and do nothing more, since durability over SMB is a questionable thing.

It's actually quite amusing how modern OSes can abstract, speed up and hide away those things that are still slow even on nowadays hardware.