Red Hat

You can:

Code:

$ cat truncate.c

#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>

int main(void)
{
        int fd=open("filename.txt", O_CREAT|O_WRONLY);
        write(fd,"HEY GUYS ALJ AF MY FACE IS A ROTTORN BANANA", 43);
        ftruncate(fd, 0);
        close(fd);
}

$ gcc truncate.c
$ ./a.out
$ ls -l ./filename.txt

-rw-r-x--T 1 username users 0 Jul 18 11:04 filename.txt

$

I also tried sleeping while another process truncates, it succeeded too.

Yes, but that is by the same process and after it has finished writing to it. I mean truncate a file that is being written to by another process.

I knew you'd say that:

I've also truncated logfiles being written to. The results were the sparse file I mentioned.

Yes, you are 100% right, it does create a sparse file. I must have not run du or not at the right moment in the past. I also normally truncate first but it did not always seem to have the desired effect in the past. I tested it now on both Red Hat Linux and Solaris 10 and although ls -l showed an ever growing file, it uses little actual space. It is also logical it happens this way..

On Solaris I sometimes seemed to have to truncate several times before it showed a lower disk usage. Might be a just a delay, maybe that is why it did not seem to work in the past.

When redirecting Bourne Shell on Solaris, there was no difference between writing and appending. In other shells the file became really 0 bytes in size when appending.. .

I do wonder if writing applications will never be bothered by such a file..

Anyway this is very good and useful information, and good insight.. thanks

thanks for all ur replies