2

I am working with a C/C++ system in a Linux environment where I am moving files using the rename() function available in stdio.h.

After the move I am need of functionality to sync this to the underlying storage to make the change permanent. If I had a file descriptor I would be able to use fsync() or fdatasync().

Is there an elegant way of doing this? Or do I have to do something like this:

rename(old_path, new_path);
int fd = open(new_path, O_APPEND | O_WRONLY);
fdatasync(fd);
close(fd);

Will that even work?

Jordfräs
  • 8,903
  • 3
  • 27
  • 30
  • 2
    Yes, it will work, though rename() doesn't do anything with the data in the file, only the metadata. For consistency of the metadata, you'd need to also fsync() the directories that rename() affects - see e.g. http://stackoverflow.com/questions/3764822/how-to-durably-rename-a-file-in-posix – nos Sep 24 '14 at 10:54

1 Answers1

1

Probably you are looking for void sync(void); function.

The sync function simply queues all the modified block buffers for writing and returns, it does not wait for the disk writes to take place.

The function sync is normally called periodically (usually every 30 seconds) from a system daemon, often called update.

This guarantees regular flushing of the kernel’s block buffers.

deimus
  • 9,565
  • 12
  • 63
  • 107
  • `sync` doesn't guarantee anything in most, if not all, operating systems. `sync` just may speed up writing some delayed writes. – Art Sep 24 '14 at 12:17
  • do you have any reliable source, which states that `sync` doesn't guarantee anything ? – deimus Sep 24 '14 at 12:44
  • Yes, me. I've written the code for `sync` in an operating system. `sync` is useless because when it returns you know nothing about the state of the file system. Disregarding weird operating system behavior where a finished write of a dirty buffer can trigger new writes, even if `sync` would guarantee that every buffer is queued for writing (which it can't) you still don't know when they'll end up on disk and if they'll be written successfully (POSIX says "The sync() function shall not return a value.", which means there's no way to report errors even if we wanted to). – Art Sep 24 '14 at 12:54
  • I've mentioned that `sync` doesn't wait for actual flush to disk, so I agree that developer cannot know when it will take place. The rest depends on the internals of a specific operating system. The POSIX spec on `sync` doesn't really cover the possibilities of errors. But lets just consider the spec as it is, so there is no way to report the error, meanwhile it claims that kernel block buffers are scheduled to be flushed. Having only the spec I can claim that it guarantees, but taking into account the abstraction layer of kernel itself, then mostly I'll agree that `sync` is sort of useless. – deimus Sep 24 '14 at 13:21
  • There can't be a guarantee without error reporting and handling, nor can there be a guarantee without a synchronous system call. The kernel can't guarantee that something will happen in the future. I call `sync`, it returns, then I pull the power plug immediately. What use is the "guarantee" then? I just proved it untrue. Especially when it comes to file system consistency it's very important to be careful about what is actually promised. `sync` is: "Do you promise that you'll write everything to the disk?" "I promise I'll try.". – Art Sep 24 '14 at 14:10
  • Unplugging the power source is a very nice example ;), but unfortunately, really many topics are not covering such use-case. Generally speaking "any" single machine instruction may fail in such situation, no matter what the specification tells about the instruction. As I've already mentioned I accept the uselessness of `sync` based on poor specification. So more or less I consider the discussion closed :) – deimus Sep 24 '14 at 15:04
  • But the point is that in case of `fsync` guaranteeing that the data has hit disk (even though that is a bit dubious considering how badly modern disks are configured) that the operations you do after `fsync` returns will happen after your file is safely on disk. So if you call `fsync`, then send a packet on the network saying "the data is safe" and then someone unplugs the power, your packet has meaning. That's why I'm a bit itchy when the word "guarantee" is used. File systems do guarantee things, even when the power gets unplugged, but only in very specific situations. – Art Sep 24 '14 at 15:44