[C,Haskell] efficient low-level file concatenation

Question

The file "foo" has been split into
foo.1
foo.2
foo.3
foo.4
To recreate "foo" on the command-line and get rid of the parts, you could do this:
cat foo.* > foo && rm foo.*
How would you do this efficiently in C or Haskell?
Approaches
create foo
write foo.1 to foo
remove foo.1
write foo.2 to foo
remove foo.2
The data of each part is duplicated once.
open foo.1 for appending
write foo.2 to foo.1
remove foo.2
rename foo.1 foo
The data of each part except foo.1 is duplicated.
Both approaches require enough free disk space to accommodate the largest part.
The best method that I can think of would be to instruct the file system to simply consider the parts as a single fragmented file in situ. This would avoid almost all disk IO and would remove the need for extra space. Are there system calls that can do that? If there are, please provide any relevant links that you have (documentation, tutorials, libraries). Searches for such calls have a low signal-to-noise ratio.
If not, could the second approach be improved?

Answer 1

@mikesd
That is exactly what I want, but even if btrfs were ready now I couldn't assume its presence. Ideally I would want something universal but as that's probably impossible, I would need at least something that's part of the POSIX standard. I realize that the diversity of filesystems probably precludes this. I was hoping that there would be some common system call because most (all?) filesystems experience fragmentation, which must mean that they are able to specify non-contiguous regions on the disk as belonging to the same file.
@itsbrad212
I only listed the first method (creating an entirely new file) to provide a comparison to the second (which I will be using in the absence of something better). I just wanted to show what I meant by "efficiency" as the second method avoids moving around the bytes in foo.1.
I agree that the difference is most likely negligible but I want something that can scale reasonably well (either to large files, or to multiple parallel operations). Besides, I find it conceptually attractive in general to minimize overhead. Even if it has no real practical effect, it's fun from a design perspective. I see programming as puzzle-solving most of the time.