Updated:Checking back, I see a lot of people tell you "no problem", "don't worry", etc. Wrong! You are right to be concerned. They do not understand the issues.
Example: have two processes which are each going to add 1 to the value in the file.
Result: file "out.txt" has the value "101" instead of the correct "102"Process 1 opens file IN, "<in.txt" Process 1 locks file IN Process 1 opens file OUT, ">out.txt"; Process 1 locks file OUT Process 2 opens file IN, "<in.txt"; Process 2 tries to lock IN and waits (The vulnerable window is greatly reduced if you use LOCK_NB, but no +t eliminated. But then you have to close and reopen IN in a busy loop +). Process 1 reads the value "100" from IN Process 1 writes the value "101" to OUT In any order (or atomically): Process 1 closes IN (thereby unlocking it) Process 1 closes OUT (thereby unlocking it) Process 1 rename "out.txt" to "in.txt" Process 2 acquires lock on file IN Process 2 opens file OUT, ">out.txt"; Process 2 locks file OUT Process 2 reads the value "100" from IN Process 2 writes the value "101" to OUT In any order (or atomically): Process 2 closes IN (thereby unlocking it) Process 2 closes OUT (thereby unlocking it) Process 2 rename "out.txt" to "in.txt"
If you use use the default blocking lock, you have a huge vulnerability. You not only have to worry about another process opening the file between your open and lock, you have to worry about any process opening it from the time you lock it until the rename is completed!
In reply to Re: Order of flock and open
by Thelonius
in thread Order of flock and open
by svsingh
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |