You can see that without any synchronization, havoc would result! Hence the next fork rule:
Fork rule #6: Open files are (loosely) shared across the fork.
The upshot of all that is this: the systems programmer must understand that, if the parent process has opened a file (or files), naively working on the file simultaneously (remember fork rule #3!) will likely cause bugs. A key reason is this: although the processes are distinct, the object they work upon, the open file, and, more precisely, its inode, is one distinct object and thus shared. In fact, the file's seek position is an attribute of the inode; blindly re-positioning the seek pointer in parent and child without synchronization will pretty much guarantee ...
