Jim Henderson wrote:
>> 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. :-)

Uh, no. That's kind of my point. You can set things up such that it 
works *JUST LIKE* a database transaction. Something fails in the middle, 
and the system automatically puts things back to the way they were.

> 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?

No. Just like a real database system, things don't get updated 
permanently until you're sure it'll work.

>> 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.

Only after you get your network connection back. Until then, everyone 
using the machine locally is screwed.

>> 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.


Cool. What's the system call in Linux that lets me change three files 
consistemtly?  I.e., I have files /tmp/One, /tmp/Two, and /tmp/Three, 
and I want to rename them respectively to /tmp/1, /tmp/2, and /tmp/3, 
and I never want any possibility of an "ls" operation on the /tmp/ 
directory to show my /tmp/One and /tmp/3 at the same time, or /tmp/1 and 
/tmp/Three.  Is there some way to accomplish that?

>> 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.

And you've never lost power either, I take it?

> Sure, and that's what package validation is for

Except that's a manual post-hoc fix that only works for package 
installs. I'm talking about something that works without intervention on 
a more generic kind of problem.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message