attempt to update locked file on windows leaves the file deleted

[Jim Hodapp]

When trying to add and then commit a file to a local working tree which is currently opened by Microsoft Word, bzr fails when trying to do the commit part. Instead of backing out of the transaction and not touching the file, it seemed to mark the file and revision as dead. Thanks to some help from the #bzr chat room I was able to retrieve the file. This is a bug however, and bzr should simply back out of trying to commit the revision and instead inform the user that another process has the file opened and locked and cannot commit.

I am attaching the log of the attempted file add and commit. The file that this occurred with is called Battery Controller CoProcessor Specifications.doc

[Robert Collins (lifeless)]

looking at the log:
 - a merge tries to replace the doc file, but fails, leaving no file there (you can move, but not replace in use files on some win32 environments)
 - a subsequent commit implicitly deletes the file (as specced).

This is kindof fodder for the 'commit should not implicitly delete' bug. I don't know that there is a lot we can do to prevent it happening; we can't tell there is an issue until the OS tells us there is, and once it tells us, we can't recover.