Actually, under Linux (and other Unix/POSIX derived systems), you can move a file while another process has it open. This is because entries in directories just point to inodes (unlike MS Windows and some other systems where the directory entry and inode are the same entity).

Caveat: If the program writing the file tries to reference the file by pathname, it won't find it. For example, if the program uses a temporary name scheme that reads the directory and looks for the "highest" lexicographical name and then "increments" that, that scheme will produce duplicate names.

I suppose a poor man's subsitute would be to just stat all the *.xml files, sleep for 10 (30?) seconds, stat them all again, and skip any where the filesize has changed. Not perfect, but probably works most of the time. Probably more reliable than just processing any file more than 2 seconds old.

Another thought...use the Linux inotify() api so that you can be more event oriented. See Linux::Inotify2. Then, every time a new file is created in the directory, you get an event. That would keep you from having to scan the directory. Though, it would increase the risk of processing a "in-use" file, so you'd need pretty good logic to determine when the file is done being written.

Does Inotify work for NFS? I think it only tells you about changes performed locally.

print "file $file is opened\n" if `lsof $file`;

... and let's hope nobody sets $file='foo ; rm -rf /'; (Shell injection). To avoid this problem, see "Safe pipe open" in perlipc and Ssh and qx.

Alexander