XCOPY and ROBOCOPY hang if file is locked nd Destination is a network drive

Question

This question was first posted to the Scripting Forum.  They indcated I should switch to the Plarform Forum.  I'm hoping this is the right place.  So ...
On my home PCs, when using XCOPY or ROBOCOPY to copy an Outlook .pst file while Outlook is open and has the file partially locked causes XCOPY and ROBOCOPY opertations to abort immediately and report the file as partially locked if the Destination is another
drive on the same PC or a USB drive.  That's good, and is as I expect.  But if the Destination drive is a network share (e.g.
\\Whatever\Whatever) then both XCOPY and ROBOCOPY hang forever - even when specifying zero retries in ROBOCOPY and even after Outlook is closed and the file lock is released.  The old DOS command COPY properly recognizes
the lock and aborts regardless of the Destination location.  But COPY won't replicate the file Create/Modify dates on the Destination location as XCOPY and ROBOCOPY do.  I'm using straight DOS from a .bat file
Anyone have any suggestions as to how to recognize this condition and avoid or correct it?

Answer 1

Ivan-Liu: Thanks for your input.  The thread you referred me to looked promising, but ultimately was not a solution. 
It focuses on ROBOCOPY and the use of an elevated command prompt. 
First of all, as I initially reported, I found the same “hang” behavior with ROBOCOPY as with XCOPY. 
Secondly, I prefer to avoid ROBOCOPY because one of the PCs I am trying to support is still running a version of Windows XP that does not make ROBOCOPY available to me. 
I have not yet tried the operation when using “run as an administrator,” but my own login has administrator privilege and still exhibits the problem. 
Moreover, the operation (both XCOPY and ROBOCOPY) always completes without issue when the .pst file is NOT locked. 
The hang-up occurs only when I forget to close Outlook before initiating the XCOPY or ROBOCOPY operation. 
I still need to confirm that the behavior is the same whether using a UNC pathname or a mapped drive name. 
But my memory is that the copy operations still hang if the file is locked when the copy operation is initiated.
The two main PCs I use are running Windows-7 (one 64-bit and one 32-bit.) 
The .pst file in question varies, but is typically between 100MB and 400MB. 
The behavior is consistent, regardless of size.  I have not tested the behavior with smaller .pst files or with other locked files of any size.
I’m now of the belief that my issue relates to the specific storage solution I have in place, which consists of an external 1TB Seagate USB drive plugged into a Belkin router, which subsequently makes the drive visible to my Windows home network as a network
drive.  I don’t know if it’s a Seagate issue or a Belkin issue. 
I’m still working to rule out Belkin by connecting the Seagate drive directly to a PC, but have not had time to complete that test yet. 
I suspect Belkin, though, because attempts to XCOPY or ROBOCOPY to a thumb drive will abort immediately and report the file is locked. 
Plus, I also have a separate problem wherein certain .xlsm files copied to the Seagate drive (when it is connected to the Belkin router) always report that they are corrupt if/when I attempt to use Excel to open the Seagate copy. 
Excel always seems to successfully “repair” the files. 
But I’ve been unable to discover a cause for that issue too.  Testing has shown that behavior to be consistent with both UNC and mapped drive names.