public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oswald Buddenhagen <ossi@kde.org>
To: kde-core-devel@kde.org, linux-kernel@vger.kernel.org
Subject: Re: kconfig's file handling (was: XFS: how to NOT null files on fsck?)
Date: Tue, 13 Jul 2004 14:53:21 +0200	[thread overview]
Message-ID: <20040713125321.GA12130@ugly.local> (raw)
In-Reply-To: <200407131431.43478.bastian@kde.org>

On Tue, Jul 13, 2004 at 02:31:43PM +0200, Waldo Bastian wrote:
> There is nothing to fix, we already use a tempfile + rename, it's in
> KSaveFile since 1999.
>
oh, indeed. i didn't dig deep enough. sorry for the noise.
the symlink case is handled differently, though (and it falls back to
in-place rewriting too early - the symlink target could be potentially
handled without in-place rewriting as well). consequently the paragraph
about in-place rewriting is valid, even if it is only a border case.

another thing to consider is a complete audit of kde regarding the
creation of files; i'm sure not everybody uses KSaveFile or equivalent
code. no, i don't volunteer. :}

> As far as I can see the problem is that the filesystem writes out the
> meta data before the actual file data hits the disk which creates a
> period of time in which the on-disk state of the filesystem contains
> trashed files.
>
yup

> I believe ReiserFS actually has an option to do things in a sane order
> so that it doesn't trash recently used files on an unclean shutdown.
> 
not only reiserfs.

> The sentiment among filesystem developers seem to be that they don't
> care if they trash files as long as the filesystem itself remains in a
> consistent state. This kind of dataloss is the result of that
> attitude, either go complain with them if it bothers you, or use a
> filesystem that does it right.
> 
the code is there, the additional integrity just doesn't come for free,
so it's disabled by default.

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.

  parent reply	other threads:[~2004-07-13 12:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040713110520.GB8930@ugly.local>
2004-07-13 12:31 ` kconfig's file handling (was: XFS: how to NOT null files on fsck?) Waldo Bastian
2004-07-13 12:40   ` Tim Connors
2004-07-13 12:53   ` Oswald Buddenhagen [this message]
2004-07-13 21:02   ` Theodore Ts'o
2004-07-13 22:28   ` Chris Wedgwood
2004-07-14  6:27 Roy Butler
2004-07-14  6:44 ` Chris Wedgwood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040713125321.GA12130@ugly.local \
    --to=ossi@kde.org \
    --cc=kde-core-devel@kde.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox