> On POSIX systems, in theory, we can just update the files in place. Except for dynamically loaded assets, this should work just fine. The OS treats file locking as advisory and open file descriptors are irrelevant, so even if the file is running you overwrite it in place and the user will get the freshest version on the next launch.
If you do this on macOS, and your code is codesigned, you are setting yourself for pain. Instead you should replace the file entirely so the file gets a new vnode.
Traditionally if you update the contents of a running binary in-place in Unix you're liable to get a SIGBUS. The way to do it is unlink the existing binary and create a new one with the same name. Which is eg what install(1) does.
That's super interesting. Tritium is signed and notarized (as is required) and uses the clean second-binary approach on all platforms, so I never ran into this. One thing that did come up was the requirement to use `ditto` rather than a standard unzipping utility to preserve some macOS-sensitive metadata.
Binaries are memory-mapped, there is no guarantee for code to be resident. Modifying a running binary hence can cause a mixture of code to be paged into a running application. Which is why unix traditionally has a special "non-advisory" file locking for mapped binaries, which tries to give you an ETXTBSY error. This is nowhere near fool-proof though, e.g. Linux stopped doing this for mapped .so files, it probably doesn't work on NFS etc.
For Windows, there is an alternative approach: simply rename the running application to a different name (e.g. app.exe to app-old-timestamp.exe). This frees up the file name which can be overwritten to any other executable. The only problem I'm aware of is that this process may leave app.exe non-existent for a moment [1], but in return a need for keeping two executables vanishes.
[1] Technically speaking I believe this can be solved with transactional NTFS (deprecated but still available as of Windows 11, AFAIK).
Can you rename applications that are currently running? Last I recall, trying to rename a binary you're currently running would lead to some weird "cannot access" errors or similar. But I mostly use Linux, maybe I misunderstood it.
Last time I came across it, I worked around it by having a "launcher" that wrote to a temporary path, closed old process, moved and started again. Slight indirection, but seemed to always work and be robust enough, compared to what we initially tried.
Love that they prioritized both privacy (no sketchy background daemons) and security (launch-time checks) for legal apps—finally a team that gets how critical "no surprises" is for tools handling sensitive docs.
Do you feel the same way about app stores too, like AppStore or Windows Store?
What is your preferred way of downloading/installation applications and keeping them up to date?
Personally I love being able to run one command and update everything in one swoop when I have time for it, instead of individually updating things all the time.
Package managers are the only sane way to install software. Even Windows + Mac OS somewhat came to realize this (even though their implementations are terrible compared to what we have in Linux land).
It's shocking that people disagree with this. Do you really want to go back to the days where you had to download installers from the internet or copy-paste random 'curl | sudo sh' lines?
Running software shouldn't even have the file permissions to change anything about its own installation.
What do you suggest as an alternative? Some kind of app store that periodically updates everything? The biggest thing package managers resolve is having everything be updated in the background, I'm tired of taking 5 minutes apart to update Wireshark everytime I use it.
If you want to do this really well I'd do it like A/B updates on Android work.
1. Have two directories for the app: A and B. One contains the "current" version and one contains (possibly) the "next" version.
2. Have the actual app you start be a separate launcher program that just picks which version to launch.
3. While the app is running, periodically check for updates. If an update is available download and unzip it to the A or B directory that isn't currently in use.
4. Next time the launcher program starts it can say "an updated version is already installed, would you like to use it" (or you can just do that automatically if you - or your user - decide that's the best option). If so it marks the appropriate A/B directory as "current" and launches that one.
Zero delay for users, works on all OSes, works with "always use the latest version" as well as "ask the user to update".
One caveat (which most apps already do anyway) is to ensure apps have at most one open instance (i.e. switch focus to the existing one), otherwise this might block both versions and result in some really confusing errors for the user, or corrupt a running app’s state if it doesn’t expect its resources to change.
> On POSIX systems, in theory, we can just update the files in place. Except for dynamically loaded assets, this should work just fine. The OS treats file locking as advisory and open file descriptors are irrelevant, so even if the file is running you overwrite it in place and the user will get the freshest version on the next launch.
If you do this on macOS, and your code is codesigned, you are setting yourself for pain. Instead you should replace the file entirely so the file gets a new vnode.
Traditionally if you update the contents of a running binary in-place in Unix you're liable to get a SIGBUS. The way to do it is unlink the existing binary and create a new one with the same name. Which is eg what install(1) does.
Not just MacOS, on Linux this is the correct strategy too.
It covers more cases: either a new instance is starting, or it hasn't fully loaded the file yet.
That's super interesting. Tritium is signed and notarized (as is required) and uses the clean second-binary approach on all platforms, so I never ran into this. One thing that did come up was the requirement to use `ditto` rather than a standard unzipping utility to preserve some macOS-sensitive metadata.
[EDIT: the post has been updated for this point. Thanks so much. https://tritium.legal/blog/update#3.]
FWIW https://developer.apple.com/documentation/security/updating-... is the relevant documentation for this if you want more details.
Binaries are memory-mapped, there is no guarantee for code to be resident. Modifying a running binary hence can cause a mixture of code to be paged into a running application. Which is why unix traditionally has a special "non-advisory" file locking for mapped binaries, which tries to give you an ETXTBSY error. This is nowhere near fool-proof though, e.g. Linux stopped doing this for mapped .so files, it probably doesn't work on NFS etc.
I use the `self_replace` crate for this: https://docs.rs/self-replace/latest/self_replace/
For Windows, there is an alternative approach: simply rename the running application to a different name (e.g. app.exe to app-old-timestamp.exe). This frees up the file name which can be overwritten to any other executable. The only problem I'm aware of is that this process may leave app.exe non-existent for a moment [1], but in return a need for keeping two executables vanishes.
[1] Technically speaking I believe this can be solved with transactional NTFS (deprecated but still available as of Windows 11, AFAIK).
This is essentially the same as using unlink on Linux, because this also keeps the file around until it is open.
Can you rename applications that are currently running? Last I recall, trying to rename a binary you're currently running would lead to some weird "cannot access" errors or similar. But I mostly use Linux, maybe I misunderstood it.
Last time I came across it, I worked around it by having a "launcher" that wrote to a temporary path, closed old process, moved and started again. Slight indirection, but seemed to always work and be robust enough, compared to what we initially tried.
Surprisingly, yes. Go does this for example.
If only desktop OS had decades to properly sort the updates out so that apps wouldn't have to reinvent the wheel...
The problem is they opted for lock-in via walled-off app stores given the opportunity.
Love that they prioritized both privacy (no sketchy background daemons) and security (launch-time checks) for legal apps—finally a team that gets how critical "no surprises" is for tools handling sensitive docs.
At least on linux programs shouldn't update themselves. This is the package manager's job.
Not everyone prefers to use package manager. I think that package manager is weird concept and should not exist.
Similarly how you shouldn't write and execute a page at the same time, a program shouldn't have the rights to change itself on disk.
Do you feel the same way about app stores too, like AppStore or Windows Store?
What is your preferred way of downloading/installation applications and keeping them up to date?
Personally I love being able to run one command and update everything in one swoop when I have time for it, instead of individually updating things all the time.
What alternative do you propose?
Whats weird about it?
Package managers are the only sane way to install software. Even Windows + Mac OS somewhat came to realize this (even though their implementations are terrible compared to what we have in Linux land).
It's shocking that people disagree with this. Do you really want to go back to the days where you had to download installers from the internet or copy-paste random 'curl | sudo sh' lines?
Running software shouldn't even have the file permissions to change anything about its own installation.
What do you suggest as an alternative? Some kind of app store that periodically updates everything? The biggest thing package managers resolve is having everything be updated in the background, I'm tired of taking 5 minutes apart to update Wireshark everytime I use it.
If you want to do this really well I'd do it like A/B updates on Android work.
1. Have two directories for the app: A and B. One contains the "current" version and one contains (possibly) the "next" version.
2. Have the actual app you start be a separate launcher program that just picks which version to launch.
3. While the app is running, periodically check for updates. If an update is available download and unzip it to the A or B directory that isn't currently in use.
4. Next time the launcher program starts it can say "an updated version is already installed, would you like to use it" (or you can just do that automatically if you - or your user - decide that's the best option). If so it marks the appropriate A/B directory as "current" and launches that one.
Zero delay for users, works on all OSes, works with "always use the latest version" as well as "ask the user to update".
I've never tried this tbf - just an idea.
One caveat (which most apps already do anyway) is to ensure apps have at most one open instance (i.e. switch focus to the existing one), otherwise this might block both versions and result in some really confusing errors for the user, or corrupt a running app’s state if it doesn’t expect its resources to change.
> An integrated drafting environment needs to be trusted with reading, editing and redlining confidential and trade secret documents.
And yet it's running on windows?!
Like it or not, confidential and trade secret documents pass through and are edited on Windows machines, among others.