I hope you get to the bottom of this, as it would rather preclude the portable recursive deletion technique detailed in this node.

One of the replies mentions that unlink under some flavours of Windows return success when the file cannot immediately be deleted because of a sharing violation. The delete request is queued up to happen when the share gets closed, and unlink returns success in the mean time (annoyingly, the file is still there and its parent directory cannot be deleted). Could this be what is happening in your case?