On Sun, 23 Nov 2008 22:57:32 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Well, sure, but dealing with every possible and conceivable exception
>> gets into areas where even in professional development it's decided not
>> to go.
> 
> No, I  mean you can make it generic. Instead of looking at each of the
> 30+ possible causes of error, you can say "Any error rolls back the
> changes."

So like "an error occurs, let's ask the user what should happen"?  Which 
is what it does. :-)

>> Well, yeah, that would fall under the category of "handling the
>> exception", no? ;-)
> 
> Not really. It's correcting an error you detected. If the error
> correction step also fails, you're pretty screwed.

That would likely happen with a disk full error - if you can't commit one 
transaction, it's going to be hard to verify and write out the old state 
as well, no?

> For example, to make things work, you need to up date the executable and
> three dynamic libraries. You update the executable, and one of the
> libraries, and then your network connection to the machine hosting the
> files fails. You can't handle that exception by rolling back your
> changes manually.

You can by reinstalling the package, though.

>> 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. ;-) )
> 
> Well, yes. That's why you have file system transactions in Windows.
> That's kinda exactly my point. If you start a kernel transaction, copy
> some files, update the registry, then bomb out, your changes get rolled
> back automatically. Just like any other database system, and regardless
> of why you bombed out or over which network the files are mounted.

And on Linux you have ext3, reiser, jfs, and other journaling filesystems.

>> 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.
> 
> Unless the error is "you pulled the plug" or "the RAID fell over" or
> something like that.

If RAID falls over, I'd say you've got a more serious problem on your 
hands....I've had that happen a few times, and it generally leads to a 
system reinstall.

>> "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?
> 
> No. Not having half-written files caused by the disk being full. Or
> having only (say) two out of file files updated because the disk got
> full while you were writing the third file.

Sure, and that's what package validation is for - but again it becomes 
moot because when the SUSE updater tries to update a file and can't 
because the disk is full, you get a big really obvious dialogue box that 
says "hey, we're out of disk space, what do you want to do?" - so you can 
clear up some disk space and say "try again".

Jim

Post a reply to this message