From: Corentin Chary <corentin.chary@gmail.com>
To: "Laurent ." <sid6582@msn.com>
Cc: linux-mtd@lists.infradead.org, artem.bityutski@nokia.com
Subject: Re: UBIFS Question
Date: Fri, 10 Jul 2009 22:01:22 +0200 [thread overview]
Message-ID: <71cd59b00907101301k7ae5a2b2j8b05d31eef1ae1fe@mail.gmail.com> (raw)
In-Reply-To: <SNT121-W16B0221E87C4D7934D7910B2270@phx.gbl>
On Fri, Jul 10, 2009 at 8:43 PM, Laurent .<sid6582@msn.com> wrote:
>
> In /mnt/alphaflight I generate a small new.txt file with vi, which contains a few lines of characters.
> After saving, I immediately power-off brutally.
> I power-on again, mount, and the new.txt file is not there...
>
> I recreate the file, I wait 20 seconds or so and power-off brutally.
>
> I power-on again, mount and now I have:
>
> -rw-r--r-- 1 1000 1000 397 Dec 31 2002 indexOnline.html
> -rw-r--r-- 1 root root 0 Jan 1 00:00 new.txt
> -rw-r--r-- 1 1000 1000 104 Dec 31 2002 obfuscAFL.bat
>
> Size 0 ... I can understand that since I did not have time to sync.
>
> It’s funny though that the file is present in the directory but the contents are not there ?
>
> If I do this programmatically, I presume I can force a sync after I close the file ?
> Is it safe to do so ? Would you know the C API to use to do a sync programmatically ?
>
Hi,
I think you should read
http://www.linux-mtd.infradead.org/faq/ubifs.html#L_empty_file
An use fsync() on your file.
Quotting "close(2) manual"
A successful close does not guarantee that the data has been
successfully
saved to disk, as the kernel defers writes. It is not common
for a file system to flush the buffers
when the stream is closed. If you need to be sure that the
data is physically stored use fsync(2).
(It will depend on the disk hardware at this point.)
--
Corentin Chary
http://xf.iksaif.net - http://uffs.org
next prev parent reply other threads:[~2009-07-10 20:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-10 18:43 UBIFS Question Laurent .
2009-07-10 20:01 ` Corentin Chary [this message]
2009-07-11 14:55 ` Artem Bityutskiy
2009-07-14 6:11 ` Laurent .
2009-07-14 7:22 ` Artem Bityutskiy
2009-07-11 15:54 ` Vitaly Wool
-- strict thread matches above, loose matches on Subject: below --
2016-03-16 9:54 UBIFS question Martin Townsend
2016-03-16 23:12 ` Richard Weinberger
2016-03-17 8:33 ` Martin Townsend
2016-03-17 8:56 ` Richard Weinberger
2016-03-17 11:16 ` Martin Townsend
2016-03-17 11:25 ` Richard Weinberger
2016-03-17 11:43 ` Ricard Wanderlof
2016-03-17 12:54 ` Martin Townsend
2016-03-17 14:55 ` Boris Brezillon
2016-03-17 15:39 ` Martin Townsend
2016-03-17 15:59 ` Richard Weinberger
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=71cd59b00907101301k7ae5a2b2j8b05d31eef1ae1fe@mail.gmail.com \
--to=corentin.chary@gmail.com \
--cc=artem.bityutski@nokia.com \
--cc=linux-mtd@lists.infradead.org \
--cc=sid6582@msn.com \
/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