On Sun, 23 Nov 2008 12:19:30 -0800, Darren New wrote:

> Jim Henderson wrote:
>> You'd have to configure things pretty weird to get part of the relevant
>> filesystems mounted in a way that was inconsistent with the
>> requirements
> 
> Sure.  However, you're looking at it from the narrow context of one
> particular program under Linux.  Being able to deal with such problems
> in a generic way is a benefit.

Well, sure, but dealing with every possible and conceivable exception 
gets into areas where even in professional development it's decided not 
to go.  It's good to deal with common exceptions, but more obscure and 
unlikely possiblities aren't any more likely to be dealt with in OSS 
development than in commercial software development.

About the only place I've ever seen 100% exception handling expected is 
in ACM programming contests.

>>>>> B) find that it's open by someone else as a shared text segment,
>>>> I don't believe that would matter,
>>> You're mistaken.
>> 
>> Well, it's something I've never run into, and I've only been running
>> Linux for about 12 years...
> 
> http://www.derkeiler.com/Mailing-Lists/FreeBSD-
Security/2002-07/10992.html

FreeBSD != Linux, but you knew that already. ;-)

> It's not really common, unless you're trying to update executables while
> they're running. It's not hard to make it happen. We've been over that
> here, a few weeks ago.

And in such a case IME the updater errors and tells you there was a 
problem.

>> Well, the installer does just that - it unlinks and creates new files,
>> near as I can tell.
> 
> Most likely. Probably because (d'oh) you can't write to a file that's
> being executed, yes? ;-)

Well, yeah, that would fall under the category of "handling the 
exception", no? ;-)

>>>>> C) run out of disk space,
>>>> That would create other problems as well
>>> Yes? So?  We know it's bad and you should avoid it, yes.
>> 
>> My point is that you would notice this probably before running out of
>> disk space.
> 
> Unless the update is what runs you out of space, or (just maybe) there's
> more than one person using the computer, like? Or some background job
> that's maybe doing something like receiving email?

Sure, and as I said, I've had that happen to me - didn't need to 
reinstall the system, had to clean a few things up, but this sort of 
thing can happen with any OS, not just Linux.  Ever try writing to the 
Windows registry with C: full?  (I knew you were waiting for me to bring 
Windows into the discussion - there you go. ;-) )

>>> And if the package manager updates the database *before* it updates
>>> the files, you might never know it.
>> 
>> If you never know it, though, then things are working as expected
> 
> And if "as expected" means "still has the security holes in it that the
> update was supposed to patch", then yes, that's as expected. Not what
> you want, but as expected. :-)

So you need to run a validation - but again as I've said a few times, my 
experience has been that an *error* condition like you describe stops the 
upgrade process, it doesn't silently say "well, that's OK" and continue 
without notifying the user.

> But yes, if you're only talking about package management per se (which
> is indeed where we started) then there are obviously solutions in place.
> It's just a shame they didn't generalize it so you can make it work for
> other people too, or over the network, or in spite of failures, etc.

"or over the network" - yeah, that works, but you have to follow special 
procedures.  Anyone who sets a system up with remote /usr or /var 
partitions knows that - or should know that.

"in spite of failures" - huh?  Update a system by writing files that 
cannot be written because of a full disk (say) even though the disk is 
full?  I'm not quite sure how you'd achieve the feat of writing to a full 
disk without causing corruption.  But again, that's why the updater 
displays an error message rather than silently failing. :-)

Jim

Post a reply to this message