On Friday 28 January 2011 03:26:42 Ted Ts'o wrote: > On Wed, Jan 26, 2011 at 06:14:42PM +0100, Olaf van der Spek wrote: > > On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler > > > > <post@hendrik-sattler.de> wrote: > > > BTW: KDE4 is a very good example for failure with modern filesystems. I > > > regularly loose configuration files when suspend-to-ram fails even if > > > the configuration of the running programs were not changed. Yay :-( > > > And this is with XFS, not Ext4! Filed a bug a looooooong time ago in > > > KDE BTS. Reaction: none! Well kde4 has a special ability for loosing configurations, i can't see any reason because a failed s2ram should destroy configurations that were not in editing-phase since months. As workaround i suggest alias s2ram=sync;s2ram Now that i think of it. We could force a sync before suspending. Maybe patching s2ram to sync() before taking any action? This wouldn't solve the problem but could help making the cases when it occurs more rare. And anyway the filesystem would be in a better state when it is fscked. > If you don't like that answer, you'll find that it's true for any > other OS (i.e., BSD, OpenSolaris, etc.) --- so either KDE needs to > get with the program, or find its users gradually switching to other > windowing systems that have sanely written libraries. I agree here, but kde guys are hard to convince that something needs to be changed... Bye -- Salvo Tomaselli
Attachment:
signature.asc
Description: This is a digitally signed message part.