> OK, so let me explain what's going on a bit more explicitly. There are
> application programmers who are rewriting application files like this:
>
> 1.a) open and read file ~/.kde/foo/bar/baz
> 1.b) fd = open("~/.kde/foo/bar/baz", O_WRONLY|O_TRUNC|O_CREAT) --- this
> truncates the file
> 1.c) wr
> The patch which is going into 2.6.30 will do this, and by default,
when you are replacing files, mostly because I know most application
programmers are going to continue to rely on this.
Nice to hear. Thank you. :-)
--
Ext4 data loss
https://bugs.launchpad.net/bugs/317781
You received this bug
> Hopefully neither is true, but in that case, the chances of a file
getting replaced by a zero-length file are very small indeed.
I expect that Ext4 is much better in performance than Ext3 and will save
me about 1 minute per day in average, (6 hours per year - about 1
additional working day), whi
I am author of current Ukrainian locale. The problem with "cal" is
described in it code. Cal is written in 2001 and not supported after
that. Here is the comment from the source code:
---
#i
I created lame test case to catch the bug. Numbers:
Filesystem, Method, Performance, Percentage of data loss
ext3, (1), 0,50, 1% (one file is partial)
ext3, (2), 0,44, 0% (one temporary file is partial)
ext3, (3), 0,37, 0% (one temporary file is partial)
ext4, (1), 0,50, 102% (all files are zeroed
> You can only fsync given a file descriptor, but I think writing an
fsync binary that opens the file read-only, fsync on the descriptor, and
close the file, should work.
Use this little program to verify your assumptions (I have no time right
now):
#include /* open(), O_RDONLY */
#include /*
I updated my "Lame test case" to include more scenarios and added
version implemented in C.
You can use it to estimate reliability of ext3/4 FS.
I will post my results (much) later - I will be busy with sport dancing
at Sun-Mon.
Can anybody prepare small QEMU or VMWare image with recent patched
