Re: Safe File Update (atomic)
On Thu, Jan 6, 2011 at 12:39 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thu, Jan 6, 2011 at 5:01 AM, Ted Ts'o <tytso@mit.edu> wrote:
>> On Thu, Jan 06, 2011 at 12:57:07AM +0000, Ian Jackson wrote:
>>> Ted Ts'o writes ("Re: Safe File Update (atomic)"):
>>> > Then I invite you to implement it, and start discovering all of the
>>> > corner cases for yourself. :-) As I predicted, you're not going to
>>> > believe me when I tell you it's too hard.
>>>
>>> How about you reimplement all of Unix userland, first, so that it
>>> doesn't have what you apparently think is a bug!
>>
>> I think you are forgetting the open source way, which is you scratch
>> your own itch.
>
> Most of the time one is writing software because it's useful for
> oneselves and others. Not because writing software itself is so much
> fun. It's about the result.
> So focus should be on what those users need/want.
>
>> The the main programs I use where I'd care about this (e.g., emacs)
>> got this right two decades ago; I even remember being around during
>> the MIT Project Athena days, almost 25 years ago, when we needed to
>> add error checking to the fsync() call because Transarc's AFS didn't
>> actually try to send the file you were saving to the file server until
>> the fsync() or the close() call, and so if you got an over-quota
>> error, it was reflected back at fsync() time, and not at the write()
>> system call which was what emacs had been expecting and checking.
>> (All of which is POSIX compliant, so the bug was clearly with emacs;
>> it was fixed, and we moved on.)
Could you point to the code snippet ? I could be worth to add to
gnulib for instance
Another point is to create some fuse filesytem for testing error
condition on filesystem. For instance a filesystem that create EIO
error randomly or EFULL, it will improve the quality of our software.
I have written such a filesystem, I will surelly post it in a few day
(hopefully)
Bastien
Reply to: