Copying a file that is written at the same time

Question

This related question can't solve my exact problem, so I'm writing a similar question.

My scenario is the following: a program (run by wine) writes to a file sized about 10-500 KB. About 1 KB addition happens on each write event (lines are added to the end of the file, no other writing methods exist), the interval between writes is from microseconds to 240 minutes. (Generally, the interval between writes is between 3 and 10 minutes, but the aforementioned time borders are the theoretically possible limits).
I cannot modify this interval, and it is random from the point of view of the user. The write interval changes, so it is possible that the ABCD write events are the following: A-B 60 min; B-C 5 sec; C-D 357.4 sec and so on.

I want to copy the file about every 25 to 30 minutes to edit it externally (automatically, of course).

What is the best solution that guarantees no race condition will appear? I don't want to write a timing algorithm, but, if it is necessary, I can do that. Also, the copying - external editing could be expanded to the interval of 1 day, no more. Wine doesn't allow me to redirect the output.

$ grep sda4 /etc/mtab
/dev/sda4 /foo xfs rw,relatime,attr2,delaylog,noquota 0 0

UPDATE

I cannot collaborate with the writing process, and the file in question is a strictly formatted plaintext file.

Answer 1

There is nothing that will provide you guarantees that you won't copy a "partial write" (from your application's point of view) in all cases, short of either:

• collaboration with that other process (i.e. a method for you to tell it to flush and stop/restart its writes)
• using a "real" transactional (database) system that allows you to take consistent snapshots/backups/dumps

Sometimes this can be worked around, if the file in question is strictly formatted. The last record, if the file was copied while non-atomic writes were in progress, will be inconsistent or partial, and your processing application could detect that, or simply ignore the last record systematically.

(Even if the application always writes its records with a single write call or equivalent, it can happen that the application is interrupted during the write call and that only part of the write has actually been processed.)