I've weird problem with my crontab job. My crontab job does the following:
program > file
Sometimes however file gets filled with random data that I can't explain.
I wonder if it could be the previous crontab job that's taking longer to run and it somehow mixes its results in file with current crontab job?
Overall my question is: is > operation atomic? Meaning if two programs do > file, then the last one to finish will have its data in file?
No, it's not atomic. Not even a little bit atomic.
The redirection does two things:
It opens the file by name, creating it if necessary.
It truncates the file.
After that, the utility is started, with its stdin assigned to the opened file.
If two scripts do that more or less at the same time, they will both end up writing the same file, but since they will have independent file descriptors, each process will overwrite the other process's output, resulting in a grand interleaving of bytes, some from one process and some from the other.
Another common race condition relates to the fact that the file is truncated (by the shell) before the utility starts executing. Consequently, even if the utility only writes a single line to the file, it is possible that a concurrent utility which reads the file will find that it is empty.
It's not atomic. You can verify it easily yourself:
( { echo a ; sleep 3; echo b ; } > 1) &
( { echo c ; sleep 1 ; echo d ; } > 1 )&
sleep 5 ; cat 1
bash > is done with an open with the flags (for bash 4.3.30 at least) O_TRUNC | O_WRONLY | O_CREAT (from line 707 of make_cmd.c)
So each will truncate the file, and write to it. If a previous process still had an open file handle it would continue writing, and at its seek position into the file, being unaware that another process had truncated the file.
来源：https://stackoverflow.com/questions/32077127/is-bash-redirection-atomic