occurring.

     (!) [Pete] From past experience I seem to remember that the only 'pure
     perl' way to ensure that a file is not being modified, without relying on
     file locks, is to check the size/mtime of the file, wait a bit, and then
     check it again, repeat until the two size/mtimes are the same.

     The reason I ran into this was because I was writing a routine to process
     a file after it had been uploaded to an ftp server. In the end, because we
     had control over the ftp server, we configured it so that the uploader and
     my routine both logged into the ftp server using the same username, and
     restricted the number of times a user could concurrently login to 1. This
     did the trick quite nicely.

     A  good  resource  for  perl  questions  is  the Perl Monks website
     [63]http://www.perlmonks.org - in fact I would go so far as to say that it
     is the best resource for perl information on the web.

     (!) [Ben] [grin] Multiple xterms are useful for this. In one of them, run
     this program:

                  See attached [64]mike.show-mtime.pl.txt

     where "foo" is the file you're looking at; this will print the mtime of
     'foo' once a second. In another xterm, open 'foo' and modify to your
     heart's content - all the while glancing at the first term. Nice and easy.

     (!) [John Karns] How about making a call to 'lsof' to see if the file is
     open?

     I'm not sure if a latency in the kernel flushing disk buffers would be a
     concern in this kind of scenario. If so, you might want to have either one
     of the processes make a call to flush the buffers to ensure that there is
     not a pending update to the file.

     In fact I've sometimes wondered about this myself: if there is a pending
     write to a file via a dirty buffer, is that automatically taken into
     account if I read the file before the buffer is flushed? I.e., is the
     pending change transparently mapped to a read of the file by libc or
     whatever?

     (!) [Sluggo] It would be a very severe bug if it didn't read from the
     buffer, since that's the official version currently. I've sometimes
     wondered  this  myself, but I've found the kernel developers pretty
     trustworthy so I assumed they wouldn't do such a thing.

     (!) [Jay] It seems to me that the kernel should update the mtime in the
     inode (as the inode is transparently cached in RAM) *everytime a write(1)
     call is made to the file*.

     So, at this point, your question expands to "if someone makes a write call
     which takes a finite amount of realtime to execute (like, writing 1MB from
     a RAM buffer to a file), at which end of the execution of that write call
     will the inode get updated?"

     IANAKH, but I believe the pertinent code is in kernel/fs/$FILESYS/file.c

     [65]http://www.ibiblio.org/navigator-bin/navigator.cgi?fs/ext2/file.c

     and specifically the function ext2_file_write() (for ext2).

     Short version:

    1. ext2 updates the inode after it writes the actual data,
    2. since it's buffered, the order in which the actual bytes hit the disk is
       indeterminate, and
    3. it's filesystem specific, since the answer to the question lives in a
       filesystem specific location in the source.

     The specific answer lies in the relative positions of ll_rw_block() and
     the assignment to inode->i_mtime in the function.

   (?) Wow, I didn't expect my question to generate such a big response. Now I
   know why I like TAG :) 

   NEways I did a little research after reading all your answers and found the
   following: 
The file modification time changes continuously when
the file is being created/modified. (For example when
creating the file using cp).

   To test this I wrote the following perl script that displays the mtime of my
   test file every 1 second: 

                 See attached [66]suramya.show-mtime.pl.txt

   Then  I opened another xterm window and ran the following command: 'cp
   /var/log/messages test.dat' 
suramya@StarKnight:~/Temp$ perl test.pl
Time: 1113452801
Time: 1113452801
Time: 1113452801
Time: 1113452801
Time: 1113452801
Time: 1113452801
Time: 1113452801
Time: 1113452890  <-- Changed
Time: 1113452891  <-- Changed
Time: 1113452891
Time: 1113452893  <-- Changed