mlprof bug

[Stephen Weeks]

Matthew:
> In any event, I understand the desire to use a rename/move rather
> than a delete followed by a copy (preserving any symlinks, etc.).
> So, the question becomes whether it should be handled just in
> mlprof, or maybe make the semantics of (src/lib/mlton/basic/)
> File.move more robust to errors.

Henry:
> You don't want to replace the rename with a delete followed by a
> copy, you just use a copy.  If you first delete the target then you
> will lose all hard links, as well as losing the permissions on the
> file and its ownership.

Here are the options that I see.

1. Replace File.move with File.copy (whose argument type should be
   changed to {from: t, to: t}) and then a delete of tmp.

2. Change the semantics of File.move so that it does (1) in the
   case of certain errors (EXDEV, others?).  

3. Implement (2) just in mlprof.

4. Don't use a tmp file in mlprof -- read the whole file in, then do
   the replaces, writing directly to dotFile.

I am undecided between (1) and (2), both of which I prefer to (3) and
(4).