And So I possess the following function:

public function append(array $data) {
    $this->connect('ab');
    if(flock($this->_pointer, LOCK_EX)) {
        fwrite($this->_pointer, $this->cleanInput($data));
        $this->unlock();
        $this->disconnect();
        return true;
    } else {
        $this->disconnect();
        return false;
    }
}

It creates a string towards the finish of the file. The file is opened up for writing although not cut down and also the pointer is defined directly in the finish from the file.

My real question is whether it's essential to copy() the file that's being written to some temporary location, email that file and replace the initial file despite the fact that I'm not truncating the file?

What's the possibility of loss of data?

The short response to this really is "No".

Using the current approach, you're obtaining a unique lock before modifying the file's data. Which means that not one other process will have the ability to customize the file when you have this lock (inside the provisions of advisory securing). One factor that's notable is that you don't test whether fwrite() was effective, that you simply most likely must do if you're worried about loss of data.

Should you copy the file and email the replicated file, you will find two problems:

  • The procedure will require considerably longer, particularly if the file is large.
  • You no more have your exclusive lock around the original file, therefore if someone else attempts to customize the file when you are carrying this out, you might overwrite their modification whenever you copy the file back.

Should you did need to make a backup from the file prior to the copy operation, that's list of positive actions - create a backup. However, you still customize the original file, not the copy. And when it fails, replace the initial using the backup, to ensure that the initial is effectively unmodified.

Really it appears in my experience that all this is unnecessary - developing a backup before every write operation is very pessimistic and can lead to a a smaller amount efficient system overall, especially as you are obtaining a unique lock around the file before carrying out any procedures onto it. But that which you certainly ought to be doing is testing caused by your fwrite() call.