safety of rename() function
 

Hi! I'm storing some important data in a file lets say "file.txt". I'm pretty fine with old version of the data, but pretty screwed if I lose it all. Algorithm currently looks like this:

(I'm writing in c++)

1) rename() "file.txt" to "file.txt.tmp"
2) fopen() "file.txt" for writing, write the data and fclose()
3) verify data and if correct remove() "file.txt.tmp"

I'm worried that first step can in extreme situation be my undoing. Can you help me here, or should I change renaming into copy-verify-remove?

Target system will be 2.6 ARM Linux, installed on "System on Module" board.

Any situation that extreme could make any part of your program your undoing. In Linux rename is a system call, so it doesn't get much safer than that. You might instead copy (manually), write the new data to the original file, and leave the backup. That will make your program safe for hard links and it will make a backup of your old data just in case.
Kevin Barry

Why would rename modify or remove your vital file? What's the concern?

If rename gets interrupted in the middle of its work the file can disappear from the file system even though the data remains intact.

ta0kira: thanks

May I ask where your evidence is for that claim? Is it independant of filesystem used too?

This should never happen if you're keeping the file on the same filesystem, unless you have either a serious filesystem problem or a serious hardware problem.
Kevin Barry

Well... it was one of my major worries exactly because I DON'T know how it works, not because I know something.

Better start assigning every variable twice then, or redoing each calculation & conditional check, just in case...

Good one, but missing the point. I know assembly language, so I know how C / C++ works "under the cover", what's reliable end what's not. Furthermore I know TTL, CMOS, so I know how assembly works. And so on... But I have never looked into Linux's source code and I have taken little interest in file systems structure.

If you are sure that rename function is safe under Linux with ext2, well... that's what I'm asking for, isn't it?

Thank all of you guys for your input.

Basically ta0kira nailed it right away, you already have to make many assumptions about how your code will be executed, but beyond doing a copy then (re)move of the old file instead of rename, you're trying to solve integrity at the wrong place/layer.
If the data's so vital, do you have checksums/redundancy codes in the format to ensure it wasn't cut off mid write without detection, etc?

The concept you're looking for is 'atomic'.
As it happens, it is
http://linux.die.net/man/3/rename

:)

And yetBut I think the point/fear was what if it isn't successful, might it leave neither, as we're talking about atomic w.r.t. host and not at e.g. processor instruction or disk drive commands level. But that's what filesystems are for, with things like journaling and copy-on-write.

Atomicity in this case depends on a properly-functioning file-system driver and properly-functioning hardware. Certainly the operation isn't atomic from the point-of-view of the kernel itself. The situations that would compromise rename could therefore compromise open, write, mmap, mknod, mount, link, unlink, chmod, chown, and probably other system calls.

You can't completely protect a single copy of your data, which is why you need to make backups with frequency and numerosity determined by the importance of the data.
Kevin Barry

On ext2 there is danger of the file not being accessible via either of the old or new names, however if there are no other names fsck will put the file in lost+found. With journaled filesystems, in the event of the operation being interrupted it either happens entirely or not at all.

The normal approach is to rename the new file into the place of the old file.