commit 61615c45fe601a188e46407db730f8acf07eb70a
author Michael Bolin <mbolin@fb.com> Wed Sep 04 09:25:42 2013 -0700
committer Michael Bolin <mbolin@fb.com> Thu Sep 19 15:04:43 2013 -0700
tree bb7985508c7163ae84c072143beaae374f8b9515
parent b46bf41240f1b691d4804d6fa15a602aea53eb76

Make sure SymlinkFileStep deletes the existing file before overwriting it.

Summary:
I encountered this issue because I was debugging something in a downloaded
tar of a co-worker's fbandroid repo. It contained the following file:

```
~/code/andrews/fb4a2$ ls -al buck-out/gen/releasebuild-properties
lrwxrwxrwx 1 mbolin mbolin 45 Sep  3 16:10 buck-out/gen/releasebuild-properties -> /Users/andrews/fb4a/./releasebuild.properties
~/code/andrews/fb4a2$
```

As you can see, `buck-out/gen/releasebuild-properties` was a symlink, but
to a file on `andrews`'s machine, which was not on my machine. When
`SymlinkFileStep` was used to overwrite `releasebuild-properties`, it threw a
`FileAlreadyExistsException` even though we did the following to delete the
file before linking it in `SymlinkFileStep`:

  if (targetPath.toFile().exists() && !targetPath.toFile().delete()) {
    throw new HumanReadableException("Failed to delete symbolic link for %s",
        targetPath.toAbsolutePath());
  }
  context.getProjectFilesystem().createSymLink(sourcePath, targetPath);

It turns out that if `targetPath` references a symlink that points to a
non-existent file, then the `exists()` call will return `false`, which
means the `delete()` method will never get executed. When the file is not
deleted, the call to `createSymLink` will throw a `FileAlreadyExistsException`.

I'm not sure whether we could encounter this issue in ordinary usage, but it
seems like a good idea to defend against it, anyway.

Test Plan:
Created `SymlinkFileStepTest#testReplaceMalformedSymlink()`,
verified that `SymlinkFileStep.execute()` threw an exception when I ran the test,
and then fixed `SymlinkFileStep.execute()` so the test passed.