1. On the one hand I see folks accessing files over and over by paths/names, and on the other hand they demand features that would break unless they switched their fundamental approach to handles/descriptors. Which is it? You can't claim descriptors would fix a problem and simultaneously insist on path-based approaches being perfectly fine. Most programs use paths to access everything (and this goes beyond shared libraries) and assume files won't have changed in between. You can blame it on the program not using fds if that makes you feel better, but the question is how do you magically fix this for the end user?
2. Do you actually see this working smoothly on a Linux desktop environment in practice, or do you just mean this is possible in a theoretical sense? Do you not e.g. get errors/crashes after an apt-get upgrade that presumably upgraded a package your desktop environment depended on (say GTK or whatever)? That happens to me frequently (and I'm practically guaranteed to see a problem if I open a new window in some program in the middle of an update), and it scares me what might be getting corrupted on the way -- makes me wish it would reboot instead of crashing and stop giving me errors.
1. In general updating the same files at the same time is not a that much of a common problem in any practical sense. The user generally won't be editing the document in two different editors at the same time. Programs use flock(2) or something similar if they have to update a shared file, or they have a directory structure that allows different instances of the program to update simultaneously by using little small files instead of having a mutually exclusive access to a single file.
I think the most common real-life problem is editing a shell script while it's still running: this happens often during development if the shell script takes a bit longer to run. You edit the file and hit save until the previous run has finished. The on-disk data changes which is reflected in the shell process that mmap()ped the script file, and eventually the contents that changed or shifted will break the shell's parser.
2. I have 106 days of uptime on my laptop. It has gone through several apt upgrades and I don't think I've shut down my X11 session for 106 days either. Firefox sometimes restarts itself after an update because it apparently knows it needs to do that but other than that I generally never restart X or reboot the machine because of updates. This has basically been the case for years, even decades. The scheme probably has to break eventually but I generally bump into other stuff such as important kernel updates before that. Fair enough for me, never really ran into any issues because of it.
1. User opens a document. User moves a higher-level directory not realizing it was an ancestor of that file. Then user goes back to the program and it can no longer find the file because it was using file paths. What should happen? Should the OS play any role?
2. You manage to keep X11 open, but that's hardly the point I was making. Do you also keep everything open and use your GUI programs as normal when going through an upgrade, or do you change your behavior in some way to avoid it messing up what you're running? And/or are you selective about which updates you apply to minimize their effects on what you're running?
Furthermore, are you familiar at all with the kinds of errors I referred to? Or have you never seen them in your life/don't know what I'm even talking about? If you don't think I'm just making things up when I say updates frequently cause me to get get crash and error messages ("Report to Canonical?" etc.), then in your mind, why does this happen right when I update? Is it just some random cosmic bit flip or disk corruption on my new computer that pops up exactly when I update? Is it not possible for it to be the update perhaps changing files when programs didn't expect them?
1) No, I think the assumption has to be that the user should know what s/he's doing. However, how would using handles even help there? If you close the file you will need to access it by a path even on Windows, and the very path has changed. Or instead, if you keep the file open and do not try to reopen it, even Linux lets you keep the file descriptor and have the program access the file as before even if it's moved around in the directory tree.
2) Yes, I generally keep stuff running as usual. I don't screen any updates, I just run them whenever I remember to. I think I've seen similar things to what you described. They're a rare exception though.
Obviously, doing something like a major update to a new Ubuntu version would make me close all programs and reboot the machine after the update. But any normal updates I just let through without thinking twice.
There will be problems eventually but the version mismatches become rather evident at that point. A configuration file format has changed or some scripts have moved, or a library has moved. I've seen Gnome Panel get messed a couple of times as Gnome gets notified of configuration file changes and the old Panel tried to load stuff meant for a new version of the Panel. I keep Emacs running all the time and I've seen it fail to find its lazy-loading lisp files some time after an update, being unable to enter a major or minor mode. I've seen Nautilus go wonky and unresponsive some hours/days after an update but killing the process fixed it. Chrome doesn't seem to mind but it gets a bit slow after a few weeks of use so it tends to get an occasional reboot even without updates. I've seen crash dialogs which don't come back after I restart the program, but again those are a handful across several years and were mostly about some long-running panel items like calendars or notification tickers.
However, all these are rare enough that I don't really feel any particular pain. It's quite indistinguishable from these complex programs rarely but sometimes still crashing on their own, all even without updates.
It generally takes a really long-winding session to run with enough cumulated big updates that majorly change things underneath that you can't just keep running the old binaries as they are. When something eventually misbehaves or crashes after the tenth or so update, I'll just restart that particular program. Most of the time the desktop itself keeps running like before. I don't recall a data loss because of live updates ever and I've used Linux since 1994 or so.
The live updates are much more convenient than restarting the whole system after each and every update just to make sure. I only restart one program when that program stops working, and like I said above even that is quite rare indeed.
As for you, you probably run programs that do suffer from this more.
I have the Gnome desktop with all its stuffses running in the background, I keep Emacs running continuously, a couple of browsers but their uptimes are generally around 1-2 weeks anway, a tmux session, then a lot of other programs which I don't keep open all the time.
But as most of the desktop still likely churns along as usually it's pretty easy to quit + relaunch a single program.
1. On the one hand I see folks accessing files over and over by paths/names, and on the other hand they demand features that would break unless they switched their fundamental approach to handles/descriptors. Which is it? You can't claim descriptors would fix a problem and simultaneously insist on path-based approaches being perfectly fine. Most programs use paths to access everything (and this goes beyond shared libraries) and assume files won't have changed in between. You can blame it on the program not using fds if that makes you feel better, but the question is how do you magically fix this for the end user?
2. Do you actually see this working smoothly on a Linux desktop environment in practice, or do you just mean this is possible in a theoretical sense? Do you not e.g. get errors/crashes after an apt-get upgrade that presumably upgraded a package your desktop environment depended on (say GTK or whatever)? That happens to me frequently (and I'm practically guaranteed to see a problem if I open a new window in some program in the middle of an update), and it scares me what might be getting corrupted on the way -- makes me wish it would reboot instead of crashing and stop giving me errors.