Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
Indeed. The Windows equivalent of rename(2) actually takes a flag that schedules the move after the system restarts, which makes lots of install/upgrade activities kind of trivial.
Day: GNOME OS
Posted Aug 8, 2012 10:23 UTC (Wed) by slashdot (guest, #22014)
This is pretty much the worst feature of Windows.
It's absolutely horrible to not be able to replace files in use, when such an operation is clearly conceptually trivial as shown by Linux.
Don't copy it please.
The RIGHT way of solving the problem is not that, but it is:
1. Install applications in their own versioned directories instead of scattering their files all over
2. Add kernel support to unlink a directory, which once the last reference drops (or after reboot) causes recursive unlink of all its contents (or alternatively, use a daemon+initscript to do the same)
3. Make applications keep the their directory open as an fd (and by keeping a connection to the daemon if using that solution), and use openat() on that fd to open their files
4. Package removal works using the new kernel unlink feature, but the directory is still accessible via the application's fd and is physically deleted only when application is closed or reboot (due to #2 and #3)
5. Package upgrade works by removing the previous version as before, then creating a new directory with a different version number with the new one, then redirecting /usr/bin/APP to that directory.
Posted Aug 8, 2012 10:39 UTC (Wed) by hummassa (subscriber, #307)
Just move it to the an application-recyclebin on uninstall/upgrade. (3) becomes unneeded, (4) and (5) become moot. And you can rollback upgrades and uninstall easily. Empty/tidy the application-recyclebin on boot.
Posted Aug 8, 2012 11:36 UTC (Wed) by slashdot (guest, #22014)
So, you need either the kernel or a daemon that can notice the application files are no longer in use and can zap then quickly.
Not totally sure on the best mechanism for that, but it's definitely possible.
Posted Aug 8, 2012 13:16 UTC (Wed) by nix (subscriber, #2304)
(Personally, I keep my versioned per-app trees around for a month to allow for later downgrading. I have never had a single problem with the script that deletes them after that much time.)
Posted Aug 8, 2012 16:41 UTC (Wed) by rahvin (subscriber, #16953)
Posted Aug 8, 2012 17:11 UTC (Wed) by drag (subscriber, #31333)
It wouldn't be difficult to put a logic into the cron job to check to see if it's on battery and delay until it's on the charger or above 80% charge or something of that nature.
Posted Aug 9, 2012 13:53 UTC (Thu) by etienne (subscriber, #25256)
Posted Aug 10, 2012 8:18 UTC (Fri) by nix (subscriber, #2304)
Far better to symlink the new things into place in some shared tree. (Of course, symlinks have slight annoying semantic changes, so a few pieces of software need adaptation to this, though maniac stow and graft users like me have already done it for most stuff. If this was really Plan 9, we could just bind-mount everything into place in your per-user /bin, and have a command that refreshed all your /bin mounts when you wanted them refreshed, flash-updating you to the latest goodies but only when you wanted it.)
Posted Aug 10, 2012 9:20 UTC (Fri) by etienne (subscriber, #25256)
Posted Aug 8, 2012 14:27 UTC (Wed) by nye (guest, #51576)
Honestly, 99% of the solution would be simply to use a flag that performs the rename not on next reboot, but when all current locks on the file have been dropped.
The kernel needs to know that anyway, so it should be possible without some nasty polling daemon, and it would turn 'reboot system' updates into 'restart application' updates, which solves the problem for anything other than updating files belonging to system processes, for which it doesn't feel so unreasonable to have to reboot.
Each version of Windows requires fewer reboots than the last, so maybe there actually is a flag that does this and it's "simply" a matter of updating the entire world to use it(?)
(Ultimately that would provide similar update semantics to Linux, which might mean the same problem described up-thread unless some thought is put into it, but it *would* mean that MS get to keep the semi-mandatory locking they love so much)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds