That's it. I want to prepend a header without copying the whole file. I want to avoid this because file are rather big, (several gigs) and a would do the trick, but i don't want to make a copy of the file (slooooow!), just insert the header.

Any ideas on this?

What sort of header are you talking about? A header found in /usr/include, some other type?

Well by a header I mean any binary portion of a file.

i.e

let the header be XXXX and my file is ZZZZZZZ I want to modify my file to be XXXXZZZZZZZ but to avoid copying ZZZZZZZ

The only way to insert data into the beginning or middle of a file is to copy or rewrite the file. Copy-replace is trivial, and almost always the best choice:
One could write a "prepend" utility to rewrite the file in place, at least in C99 or GNU C, using low-level I/O routines (from unistd.h). The trick is to use an output buffer large enough to fit both the input buffer and the prepended data, and to always refill the input buffer to the brim before flushing the output buffer, so you will never overwrite yet-unread data in the file. It would not be faster than using cat, but it would not need/use the extra disk space, not even temporarily. The problem is that if you happen to have an I/O error midway through, the file will be mangled. Using cat, you still have the original file.

The only way I can think of that you can do that is if your file is marked in some way that allows you to search for a beginning mark and copy to an ending mark. That means you'd have to section that file using unique patterns that can be found by whatever utility you want or roll your own C, C++, whatever, whatever program to do the extraction. Even if you knew the beginning and ending addresses in the file, you could extract that way (but you'd have to write a program to do it).

Another way might be a DBMS, such as MySQL, PostgreSQL, etc. Put your header stuff in a table with an index so you can extract it on-the-fly using a where ind_val = some_pattern.

This is only one approach, perhaps you can think of others.

Hope this helps some.

In some cases it may be acceptable to generate the concatenated stream and pass it directly to the receiving program without storing the data on disk again. For example, to pass a stream with two concatenated files to a program called "zorb":Note that this is not replacing the command's standard input. The argument list will contain the name of a pseudo-file in /proc, which the program will need to open by name to see the content, as it would with an ordinary file.

Disadvantages include

1. Since input is coming from a pipe, the program won't be able to do seeks or see the metadata for the actual input files.
2. If the program wants to complain about something in the file, the reported file name will be something useless like, "/proc/self/fd/63".