On Mon, 26 Mar 2012, Tim Connors <tconnors@rather.puzzling.org> wrote:
kde (and gnome) programs have a long history of failing to do even the most basic of atomic file operations (I'm not talking of failing to do fsync() here, I'm talking simply open(),write(),close() as being their entire file writing sequence)
perhaps kmail is frequently updating its dotfile?
KDE programs do frequently update things. Some years ago the kmail code which wrote messages to disk returned an unsigned integer to indicate the index (starting from 0) of the message that was written - this left no possibility of a return code indicating error. So when you ran out of disk space mail just disappeared!
Get a better desktop environment and mailer :)
KDE is very user friendly and if you are moving from a CUA environment it can be configured to be familiar. There are many objective criteria by which KDE scores very well. But data integrity probably isn't one of them.
On Friday I downloaded a zip file and unpacked it. I then spent some time browsing the HTML documentation in the unpacked directory. Hours later, after the crash, many or most of the HTML files I had read had size=0.
XFS is perfect. You and the multitude of other people over the years that have reported this very same problem of 12 hour old files disappearing, must all be mistaken. QED.
Actually a large part of the problem here is apps expecting things that POSIX doesn't guarantee. XFS delivers fewer of the things that certain app developers expect but that POSIX doesn't require. Programmers should learn about what filesystems are required to deliver and code accordingly, assuming that the success of write() means that data is on disk is just wrong. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/