Solaris

Truncating an open file is not guaranteed to work. The mode the file descriptor is in matters, as does the ability of the underlying file system to support sparse files. If the mode is "wrong", and I think "wrong" can depend on a lot of things, but in this case I think if the file wasn't opened with O_APPEND flag set is what's most important, the next time the process that has the file open writes to the file, the data will go to whatever the current file offset is for that open file descriptor. If the underlying file system doesn't support sparse files, and the current offset is 6 GB into the file, now that file you truncated is suddenly once again 6 GB in size.

In short, if the file is created like this:

Code:

daemon.process >> log.file

You should be OK if you truncate that log file.

If it's

Code:

daemon.process > log.file

You can't be sure that truncating log file will stick.

This isn't really a simple issue - the specific OS matters, the specific file system matters, the specific flags set on the open file descriptor matter, and the actions the process performs on the open file descriptor matter.

Try it:

Code:

cat /dev/null >> /some/file &

Let the file grow to a good size, then

Code:

cp /dev/null /some/file

Now try

Code:

cat /dev/null > /some/file

Truncating the file is guaranteed to work, i.e. to release the disk space, in the OP context. The question clearly mention the underlying file system is ZFS. In any case, all file systems supported on Solaris support sparse files outside FAT32.