Extracting on top of existing files isn't quite right

[fadden]

Repro steps (Linux):

1. Get an archive with a locked forked file. For example:
   • Create a forked file using the file preservation extensions. You can do this by creating files called "ReadMe#505445" and "ReadMe#505445r". (You can also just extract a forked file from an archive with "nulib2 xe ...".)
   • "Lock" the files with "chmod 444 ReadMe*".
   • Create a new archive using "nulib2 ae foo.shk ReadMe*". The archive should have a single, forked entry.
2. In an empty directory, extract the archive with "nulib2 xe foo.shk". You should get two files, matching the originals.
3. In that same directory, extract the archive again.

NuLib2 will not overwrite the existing entry. This may or may not be considered a bug, as the existing file is "locked" and should not be casually overwritten. However, if NuLib2 is prompting the user for permission to overwrite, there's no reason not to continue if permission is given.

If you elect to rename the file, or not to extract it at all, NuLib2 will move on to the resource fork, which it will attempt to extract regardless of what you choose for the data fork, and without prompting for help when it encounters the existing file. It just fails. NuLib2 should rename or skip the resource fork according to the requested handling of the data fork. At the very least it should re-prompt for rename or skip when the resource fork extraction fails.