ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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?
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
If rename gets interrupted in the middle of its work the file can disappear from the file system even though the data remains intact.
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
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?
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
Quote:
This rename() function is equivalent for regular files to that defined by the ISO C standard. Its inclusion here expands that definition to include actions on directories and specifies behaviour when the new parameter names a file that already exists. That specification requires that the action of the function be atomic.
If a call to rename succeeds it is guaranteed to have been atomic from the point of view of the current host (i.e., another program would only see the file with the old name or the file with the new name, not both or neither of them).
But 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.
But 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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.