3

I use a simple code:

File.Copy(source, destination, true);

To copy a file from a UNC path (source) to a local path (destination). The third parameter makes it that if the file is already there, it will be overwritten.

This works 99%. However, when the source file is locked, I sometimes saw this error:

The process cannot access the file '\xxxx\aaaa.dll' because it is being used by another process.

Then the destination file still disappeared. I can only think that File.Copy first deleted the local file and then when it is trying to copy things over, it failed and throw exception?

It that so, and how can I prevent this?

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
daxu
  • 3,514
  • 5
  • 38
  • 76
  • Have you tried the method from this question? : http://stackoverflow.com/questions/2781357/file-being-used-by-another-process-after-using-file-create – Bcpouli Jul 28 '14 at 21:16
  • This is extremely common exception. The problem is what it says. The file is locked by other process. – Andrey Jul 28 '14 at 21:17
  • What is an `unc` path? – jmstoker Jul 28 '14 at 21:18
  • 1
    @jmstoker: Essentially a network path, rather than a local device. – Robert Harvey Jul 28 '14 at 21:18
  • 1
    @jmstoker Universal Naming Convention - Windows-specific – Drew McGowen Jul 28 '14 at 21:18
  • @daxu: Why wouldn't it be possible? – Robert Harvey Jul 28 '14 at 21:19
  • I think you should test it by locking the file yourself and seeing if File.Copy deletes it. Then post the answer. I am curious to know! This would be a good thing for Microsoft to specify in the documentation. – Moby Disk Jul 28 '14 at 21:20
  • 1
    @MobyDisk: All that will tell you is that the locking system works. Clearly it deleted the file; locking it first will just prevent its deletion. – Robert Harvey Jul 28 '14 at 21:20
  • @RobertHarvey I meant lock the source file. I thought daxu is asking "Is it possible that File.Copy deleted the file?" It sounds like it does, and a simple test would verify that. – Moby Disk Jul 28 '14 at 21:22
  • @MobyDisk The OP is not describing deletion of the source file, but of the *existing target file having the same name.* Read the question closely, folks. – Robert Harvey Jul 28 '14 at 21:23
  • @RobertHarvey: Yes, I see that. That is why I propose the test. He sees the file is deleted, and seems to assume that File.Copy deleted it. I propose he test it. If he already saw it do this and knows it, then there is no question. Merely a statement that file.Copy does this. – Moby Disk Jul 28 '14 at 21:24
  • I find this behavior weird. This case is barely documented but internally calls Kernel32's [CopyFile()](http://msdn.microsoft.com/en-us/library/windows/desktop/aa363851(v=vs.85).aspx) function. Comparable operations are (not necessarily documented to be) atomically, i.e. only removing the old file after the entire operation successfully completes (copy to temp file, delete target, rename temp to target). Can you create a small code sample that reproduces the problem? – CodeCaster Jul 28 '14 at 21:24
  • @MobdyDisk You don't need a lock to tell you that. All you need is to execute that single line of code (perhaps in the debugger). – Robert Harvey Jul 28 '14 at 21:25
  • @RobertHarvey: He needs to execute that single line of code, but with the source file locked. Simply running that line of code with the source file not locked will copy it, and tell him nothing. Like CodeCaster says, the idea is to reproduce the problem. – Moby Disk Jul 28 '14 at 21:27

2 Answers2

3

Could not reproduce.

File.Create(@"c:\test\source.txt");
File.Create(@"c:\test\target.txt");
var stream = 
    File.Open(@"c:\test\source.txt", FileMode.Open, FileAccess.Read);
File.Copy(@"c:\test\source.txt", @"c:\test\target.txt", true);

throws the exception, but preserves the target file.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
2

ProcMon showed me the destination file is not accessed when the source file throws a sharing violation upon opening.

The code shown does not even touch the destination file when the source file is locked, let alone delete it.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • this only happens extremely randomly, also the unc path (the source) has dfs enabled on the folder. Will that have any impact? – daxu Jul 28 '14 at 21:43
  • The copy function does not seem to even bother about the destination file when the source file is not readable. It would be pretty inconsiderate when the destination file would be deleted regardless the source file is readable. Would you expect `Copy("nonexisting", "existing", true)` to remove the existing file? Are you sure the _destination_ file gets deleted by _your program_ when the _source file_ is locked? – CodeCaster Jul 28 '14 at 21:46