> I often test these apps on the local file system. The atomic flag prevents me from doing such tests [ ... ]
Good point. I agree that if the local file system cannot perform atomic renames then the atomic flag would probably be counterproductive. When atomic is specified, we could exec 'mv', which is atomic when used within a filesystem. We have DF#getFilesystem() that we can use to determine if two files are on a common filesystem. So I think we could probably could implement the ATOMIC option correctly for the local filesystem if we wanted.
It looks to me like S3 implements atomic copy. So you still need to remove the source as a second step, but one can presumably tell by dates that the copy succeeded, so the failure cases are not as bad, but I don't know if that's good enough.
More generally, would throwing an exception for filesystems where the rename cannot be done atomically ever be useful? Let's say that we don't feel that S3 implements atomic rename sufficiently well. Would it be better, when an application wants an atomic rename, to perform the rename non-atomically or to throw an exception? If the application's okay with non-atomic, then they shouldn't specify ATOMIC. So then the question becomes, should any applications ever specify ATOMIC? Is it ever so important that you'd rather fail than have it non-atomic? My guess is probably not, so perhaps we should, as you suggest, skip the ATOMIC option. What do others think?
Even if we only have a single option initially, OVERWRITE, we should still probably make the method accept multiple options, to future-proof it. Also note that, if the signature is new, we may not need need a different name!