Re: Safe file update library ready (sort of)
Ian Jackson <email@example.com> writes:
> Shachar Shemesh writes ("Re: Safe file update library ready (sort of)"):
>> I'm sorry, it might be me, but I fail to see the overlap between the
>> functionalities of safewrite vs. userv. The premises for safewrite is
>> that a program wants to make sure data integrity is maintained when
>> writing files. Userv seems to be about trust and a user level tool. The
>> two seem to revolve around two completely different interpretations to
>> the word "safe", as well as two completely different use scenarios.
>> Am I missing something here?
> Sorry, I replied to the wrong message. I meant to reply to Adam
> Borowski's comment, where he wrote:
> ] There's a race condition:
> ] while [ 1 ]; do ln -s /etc/passwd somefile.tmp; done
> ] "Hey root, could you please use this program using libsafewrite on
> ] 'somefile'?"
> Having said that, I don't think the concept behind your library is
> sound, because it presupposes that all previous programs which update
> files are buggy.
> Just because some wrongheaded Linux kernel filesystem developers think
> that almost all previously written Unix programs are buggy, doesn't
> mean that it's true or that the right fix is to rewrite every program.
I think you are dead wrong there Ian. Even if every single program is
dead right (and we know a lot aren't) that means every one of them has
a safe file update function somewhere in it.
A function doing exactly the same thing in many programms. Doesn't that
just scream for a shared library?
Add to that the number of programs that don't yet do file updates in a
safe way and need to be fixed I think the project is a verry good
idea. The unexpected behaviour of ext4 is just a minor implementation
detail to take care for a general safe update function.
So Shachar don't get discuraged by the ocassional nay sayer.