ROBUSTNESS: Are JobCollection objects written atomically?

Vignette 'Migrating from BatchJobs/BatchExperiments' says:

• "Nodes do not have to access the registry. submitJobs() stores a temporary object of type JobCollection on the file system which holds all the information necessary to execute a chunk of jobs via doJobCollection() on the node. This avoids file system locks because each job accesses only one file exclusively."

What happens if master reads such a JobConnection file before it has been fully written? Sure, the chance for this should be small, but with 10,000-100,000's of jobs, could this happen? If it could happen, I wonder if the file format can protect against this, e.g. an generate at least a parse error, or in the worst case, silently parse the incomplete file.

If not already written atomically, could it be achieved by simply writing to foo.rds.tmp which is then renamed to foo.rds only when saveRDS() is complete? (Here I'm just assuming you're using RDS files).

Start with the “Migrating from BatchJobs/BatchExperiments” vignette and trace submitJobs() and doJobCollection(). Inspect how JobCollection files are written and read, and determine whether a concurrent read can observe incomplete data. Done means the atomicity behavior is documented and, if needed, protected by an appropriate regression test.