Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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


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

share|improve this question
up vote 1 down vote accepted

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.)

share|improve this answer
Use hardlinks. Create another hardlink and use that file for processing(tail) – Nikhil Mulley Jan 4 '12 at 10:46
That doesn't solve anything. The processing app could read a "partial" write from the "logger" app with a hardlink (just as it could reading the file directly). – Mat Jan 4 '12 at 10:47
The file is strictly formatted (I forgot to write it in the question), so your solution works. I am waiting for other solutions before set your answer to accepted. – WavKuFoo Jan 4 '12 at 10:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.