Corrupt files?

I have some background C app code which saves data to a file (it doesn't happen very often):

 

FILE *f;

// Make rw
system("mount -o remount,rw /opt");

// Open file for writing
if ((f = fopen(BuildFile, "wb")) == NULL)
	return 0;

fprintf(f, "Version = 5\n"); // There are more lines than this...
fclose(f);

// Make ro
system("mount -o remount,ro /opt");

 

This generally worked but I am getting reports of the file being corrupt after repowering. I have witnessed the file be reported as present and has a size from the ls command. Editing with pico shows an empty zero line file.

 

The file is present and has content until the power is cycled.

 

Doing a manual remount from a terminal seems to clear the error.

 

1) Can you see a flaw in this approach? It seems to be recommended in other posts

 

2) Would an fsync() call be a good idea?

 

3) Is there a difference remounting /opt or / ?

 

4) Is there a problem with the system command from an app compared to a terminal?

 

5) Is there an application note detailing the filesystem on your card, and what is synced where, and what persists, and the boot sequence? There are a lot of mounts and I would like a fuller understanding.

 

Cheers!

Nothing very out of ordinary. I would not use binary mode (“wb” use “w”). The “fsync()” may be required as Linux may be buffering the file and not yet writing it to the file system until after you remount back to “ro”. It is always a good idea to make writable to PPMAC stuff only so “/opt” is preferable to”/”. The "system()" use is OK.

OK thanks for clearing up some of that. So what could be causing a 915B file to have text content after executing the app, but then no content (but still 915B) after cycling the power?

 

So far a colleague has seen it on a customer machine (we are now supplying PPMAC systems and looking a bit stupid), and I have seen it in the office.

 

When it gets in this state it is repeatable. After manually executing the "mount" command in a terminal it seems to clear up. We have to be able to do this automatically to spare users from terminals, but this is in danger of making the product unusable.

 

I have never seen it on my machine but my card seems to have some differences. The /opt/ppmac folder has different contents (I forget the names but the ones that have shown the problem have some .sh files and others). Are there different distributions?

 

Also the office one that went wrong had "fsck: There are differences between boot sector and its backup" with one difference, mine doesn't. A clue? A problem?

 

We are very worried about this

Using the “fsync()” should remove the need for the manual “mount” in Linux. Send us the boot output to see the differences you are getting.

I will attach dumps of the boot text. The interesting differences are:

 

* The card I have never seen fail is booting in Fast Boot, the card I have seen fail is running fsck.

 

* The card I have seen fail is running OpenBSD Secure Shell server, what is that?

 

* The card I have seen fail only has one ". ok" after "initializing module rtpmaclib", is this OK?

 

I will also attach dumps of the /opt/ppmac folder, why are they different?

 

I will also attach dumps of "fsck /opt". There is an error on the card I see go wrong, is this a problem?

 

I don't have access to the other cards that have gone wrong, and those and this one are currently in a working state (i.e. have not latched in to the corrupted state at the moment).

 

What would you like me to check next?

 

Cheers

Dave

boot_ok.txt

boot_bad.txt

fsck_ok.txt

fsck_bad.txt

optppmac_ok.txt

optppmac_bad.txt

I think the only differences here are “original” firmware version and Linux build. The firmware people say there are no unusual things reported.