Brian Stansberry wrote:
Is it easier just to copy the exploded deployment and have the scanner keep the copy in sync. I've done that for farming; it's not such a big deal. I'm starting to feel like not doing that is leading to a lot of internal complication (e.g. needing to keep track of multiple locations where content is stored.)
That doesn't solve the atomic move problem, but maybe if people can't do atomic moves they should [not] use the filesystem as their deployment API. :)
For a single JAR it's a much simpler proposition to avoid partial copies than it is for exploded deployments. One merely has to ignore files which were modified in the past, say, 500 ms. This very greatly reduces the likelihood of a partial copy without really sacrificing latency significantly.
This doesn't work for directories as most filesystems won't update the directory timestamp when one of its children are updated, and in no cases I can think of offhand for deep children.