fflush does not flush

[guich]

Hi,

I have an application that uses fopen and, from time to time, calls
the fflush to flush data. However, from my tests, seems that the
fflush is not working.

I have a simple test: open a file, write something, call fflush, then
remove the battery. If you go back, you'll see that the data was not
saved to disk.

This test only works if you call fclose before removing the battery.

Question: if there any way to force Android to write the data without
closing the file?

thanks

guich

[fadden]

On Jul 1, 2:36 pm, guich <guiha...@gmail.com> wrote:
> I have a simple test: open a file, write something, call fflush, then
> remove the battery. If you go back, you'll see that the data was not
> saved to disk.

First and foremost: fflush() flushes the buffer in your process,
causing a write() call. This does *not* do a synchronous disk write.
For that, you need to use fsync(), which takes a file descriptor (so
after you fflush(fp) you would fsync(fileno(fp)).

This also does *not* generally guarantee that your data is written --
many hard drives have an on-board write cache -- but on an Android
device with flash ROM I believe it's safe to assume that it will be
committed by the time you pull the battery out.

> This test only works if you call fclose before removing the battery.

I don't know why fflush() and fclose() would behave differently here.
If they do, there might be a bug.

[Olivier Guilyardi]

Needs checking, but if fclose() performs a bogus fynsc() then that might explain
certain lag/freeze in my app.

--
Olivier

[Baodong Chen]

sdie question:
on some devices, when i pull out the sdcard and afrer a few seconds i
pull the sdcard
in,after the notification says the sdcard is mounted, i start my
app,and i find that some
io functions like fopen fseek fread sometimes still fail? why this happened?

> --
> You received this message because you are subscribed to the Google Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
>
>

[Olivier Guilyardi]

Before doing anything with the SDCard, I personally check that:

Environment.getExternalStorageState().equals(Environment.MEDIA_MOUNTED)

HTH

Olivier

[Dianne Hackborn]

Everyone should read Tim Bray's blog post on syncing data:

http://android-developers.blogspot.com/2010/12/saving-data-safely.html

Also as a general rule, given that you are following the rules given there, I don't think you should be asking the question "is the last data I wrote actually on disk if I pull the battery out after writing it."  That really isn't so important.

What *is* important is "no matter when I pull the battery out, is my not corrupted."  For most code this means that when you next read your data you end up with either a consistent view of the old data *or* a consistent view of the new data.  It is fine if you pull the battery out immediately after writing your new data and when you next run you get the old data in what you had last written was lost.  You just don't want to end up in a situation where your data is corrupt.

A useful tool we have for this that is used by code inside the platform is AtomicFile:

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/com/android/internal/os/AtomicFile.java

That is of course Java code...  given I am posting this on the NDK list, I guess you could use that as a model for implementing a native version. :)

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.