I have a Java application that monitors a folder for incoming XML files. When a new file is detected I need to test the file that it is not currently being updated and is closed. My thought is to use File.canWrite() to test this. Is there any issue with doing this? Is this a good way to test that a file has been completely written?
Other ideas I am throwing around are:
- Parse the incoming XML file and test that the closing tag is there.
- Check for the EoF character.
I just am not sure that any of these methods will handle all scenarios.
No, canWrite is not suitable for this purpose. In general the file will be writable even if another process is writing.
You need a higher level protocol to coordinate the locking. If you plan to use this code on a single platform, you may be able to use NIO’s FileLock facility. But read the documentation carefully, and note that on many platforms, the lock is only advisory.
Another approach is to have one process write the file with a name that your process won’t recognize, then rename the file to a recognizable name when the write is complete. On most platforms, the rename operation is atomic if the source and destination are the same file system volume. The name change might use a different file extension, or even moving the file from one directory to another (on the same volume).
Since in this case you are working exclusively with XML, looking for a close tag would work, but it isn’t foolproof—what if there are comments after the final markup, or the writer or simply doesn’t write valid XML?
Looking for the EOF will not work. There will always be an EOF, even when the writer has just opened the file and hasn’t written anything yet. If this weren’t so, the easiest thing would be to allow the reader to start parsing as soon as the file showed up; it would simply block until the writer closed the file. But the file system doesn’t work this way. Every file has an end, even if some process is currently moving it.