All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Iram Shahzad <iram.shahzad@jp.fujitsu.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBIFS recovery truncates file to zero size
Date: Thu, 12 Mar 2009 11:11:25 +0000	[thread overview]
Message-ID: <20090312111125.GB6995@shareable.org> (raw)
In-Reply-To: <B2B24529967640E8A501ADADDE1E9908@sky>

Iram Shahzad wrote:
> >>For the write back enabled case, I was expecting the
> >>following behaviour:
> >>    power went down before the file is sync-ed, so
> >>    on the next booting the file will be in its old state,
> >>    that is it will contain the contents which it had before
> >>    this write.
> >>
> >>But instead of being in the old state, it becomes empty file.
> >>Is this really expected(correct) behaviour?
> >
> >No.  How were you updating the file?
> 
> The file is updated by a Java application in the following way.
> 
> -----
> FileOutputStream str = new FileOutputStream(aFilename);

"new FileOutputStream" truncates the file.

> I switch off the power after confirming that the str.close() has been
> executed.
> 
> P.S:
> If I add str.getFD().sync(); after the str.flush(), the file looks good in
> the next boot. However my question still remains for the case
> when I do not call str.getFD().sync:
> "why the file becomes empty rather than being in its old state?".

str.getFD().sync() won't be reliable if you lose power _between_ "new
FileOutputStream" and sync().  If that happens, the file may still be
truncated.

If you are just appending data, use "new FileOutputStream(aFileName,
true)", write, flush, sync, close.

If you are changing the file contents, instead write to a temporary
file in the same directory, then sync the temporary file (after
flush), then do an atomic rename over the original file, then open the
directory and sync that somehow.

-- Jamie

      parent reply	other threads:[~2009-03-12 11:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-11  9:16 UBIFS recovery truncates file to zero size Iram Shahzad
2009-03-11  9:51 ` Brijesh Singh
2009-03-11 10:31   ` Adrian Hunter
2009-03-11 18:13 ` Reuben Dowle
2009-03-12  2:44   ` Iram Shahzad
2009-03-12  8:26     ` Adrian Hunter
2009-03-12  8:49       ` Iram Shahzad
2009-03-12 10:25         ` Adrian Hunter
2009-03-12 11:08         ` Artem Bityutskiy
2009-03-12 11:11         ` Jamie Lokier [this message]

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=20090312111125.GB6995@shareable.org \
    --to=jamie@shareable.org \
    --cc=iram.shahzad@jp.fujitsu.com \
    --cc=linux-mtd@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.