Solaris

Getting an app that does not like to open and close the log to move to a new file is impossible. Many servers are set up to close all logs and reread all configs when you signal them with SIGINT. Others assume they can write forever, being written by HS kids!

You might be able to put a named pipe there, and write your own process to read that named pipe and change logs periodically. Some apps may not accept a named pipe. If you put two servers under a load sharing and relibility tool, you can take down one to reset the log and when it is back up, recycle the other.

This is slightly incorrect, at least when using UFS or ZFS. If the writing program is seeking to the previous end of the file location, the space from the beginning of the file to that new location isn't filled with zeroes but unallocated, leading to the creation of a sparse file. If you read the unallocated data, the OS will return "virtual" zeroes but they use no space at all on the disk.

I was taken in by the zeros! You can close it, and there is no space allocated? I guess it is all done in the allocation storage. It is an interesting resource in the 64 bit world, as you could have a very huge, sparse file with just a few blocks. Consider how handy that is in conjunction with mmap64().

This space isn't allocated whether the file is closed or not.
A simpler approach is to mmap /dev/zero which is kind of an infinite sparse file by design.

The idea is that you could has a key to calculate an address in a virtually huge and actually small file of unallocated blocks and write or fetch a piece of data there, as long as you accept nulls as a miss on a fetch. You can write a sparse file. Pages are allocated only as they are written into the sparse matrix. Current hash maps must drop the key to the modulus of the bucket count and use an array of pointers to indirectly find the bucket data, if the bucket has been created. Here, you can drop the hash to 8 bytes and seek directly to your information within the sparse file. With a mmap64, the seek is just reach out and touch it! Of course, your key generation must leave space for the bucket between possible 64 bit addresses. I guess if the bucket is occupied, you might permute the address in some standard way to pick a new bucket address in a place not likely occupied. Think stock symbols, 1-5 bytes uppercase in a very time dependent industry, like an elecronic order book and matching engine, for instance.

Now that we know what you actually want we can give you better advice.

You shouldn't be handling logfiles this way if you can possibly avoid it. Many daemons let you safely truncate the logfile: : > /path/to/logfile ...and the daemon will start writing from the beginning again. Others will recreate the file when deleted. Others want SIGHUP sent to the daemon process to tell it to truncate or rotate its own logfiles.

If the daemon is so badly written as to force you to hack things with fuser instead of these methods you should get it fixed or replaced.