in reply to When is it safe to move a file?

Hmmm, my thoughts.

Use stat to compare the inode access/modify/change times for the data and control files. Also check that the control file is big enough to be finished. If all the inode times are near equal, and the files are resonable sizes, you may be able to assume the file is okay. 

my $name = 'foo.txt';
my $cnrl_name = $name . '.ctrl'; 
if ( ((stat($cnrl_name))[9] > (stat($name))[9]) and ((-s($cnrl_name))>
+10) )
{
  copy $name, "dir/$name";
  unlink $name, $cnrl_name;
}

[download]
It would be better if filenames were always unique or the ftp server used flock or lockf on the files, but it may be possible to deal with your problem. I have no idea if this solution will work, I really don't know all that much about inodes and stuff.

Replies are listed 'Best First'.
Re: Re: When is it safe to move a file?
by BoredByPolitics (Scribe) on Jan 14, 2001 at 19:00 UTC

    Thanks repson - I'll give that a go and see how I get on :-)

    Pete

[reply]
      I'd strongly recomment that you follow kschwab's advice and rename the data file to the same directory before you start to copy or process it. Copying takes time, and you don't want the remote process to start updating the file while your process in in the middle of copying it. Renaming it first will help prevent that.

      Then, after you rename it, check to see if it's still changing, because it's possible that the remote process opened the file just before you renamed it.

      There's still a race condition, but it's much smaller. Proper design would have been for the remote program to never send the same data twice and never use the same filename twice. I also recommend that you find the person who designed this broken protocol and kick them in the ass.

[reply]

In Section Seekers of Perl Wisdom