>>
>That shows how to lock/unlock a file, not how to read an already
>locked file (most probably locked in another process)
>
Yes, i just wanted to point out that he could unlock the file using
the code then he could copy it.
>
No you can't "unlock" a file "locked" by another process. Where "locked"
means opened exclusively, that is, non shared.
You can only use the "shadow copy services " to copy such file(s). The
shadow copy services API's aren't covered by the framework however.
The Volume Shadow Copy service supports backing up locked files. There is an
API for this, which I have used via a batch file with script to backup the
Registry, but that's about as much as I can tell you.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short Urls & more: http://ittyurl.net
"jim" wrote:
Is there a way (using VB.Net or C#) to copy open or locked files?
>
Thanks!
>
jim
>
>
>
You can use the CopyFileA Win32 API function to copy open files:
Private Declare Function apiCopyFile Lib "kernel32" Alias "CopyFileA" _
(ByVal lpExistingFileN ame As String, _
ByVal lpNewFileName As String, _
ByVal bFailIfExists As Integer) As Integer
Here is an example call:
intResult = apiCopyFile(str Source, strDest, 0)
I don't know of a way to do this with managed code.
"Wayne" <me@nospam.comw rote in message
news:OET$$UbmIH A.2268@TK2MSFTN GP02.phx.gbl...
Jim,
>
You can use the CopyFileA Win32 API function to copy open files:
>
Private Declare Function apiCopyFile Lib "kernel32" Alias "CopyFileA" _
(ByVal lpExistingFileN ame As String, _
ByVal lpNewFileName As String, _
ByVal bFailIfExists As Integer) As Integer
>
Here is an example call:
intResult = apiCopyFile(str Source, strDest, 0)
>
I don't know of a way to do this with managed code.
What makes you think you can copy "locked" files by calling this API, which
is exactly the API wrapped by System.Io.File. Copy.
This seems to work fine for me using Vista Pro. I have tried it on a couple
of different file types/applications (MS Word, AutoCAD, etc.) with open
files and this seemed to copy them anyway. The function returns a 1 and the
file copy is created. I tried deleting the files and they are definitely
locked. No dice there. Perhaps this is a Vista phenomenon?
"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:%23BQtgybm IHA.5024@TK2MSF TNGP06.phx.gbl. ..
"Wayne" <me@nospam.comw rote in message
news:OET$$UbmIH A.2268@TK2MSFTN GP02.phx.gbl...
>Jim,
>>
>You can use the CopyFileA Win32 API function to copy open files:
>>
> Private Declare Function apiCopyFile Lib "kernel32" Alias "CopyFileA"
>_
> (ByVal lpExistingFileN ame As String, _
> ByVal lpNewFileName As String, _
> ByVal bFailIfExists As Integer) As Integer
>>
>Here is an example call:
> intResult = apiCopyFile(str Source, strDest, 0)
>>
>I don't know of a way to do this with managed code.
>
What makes you think you can copy "locked" files by calling this API,
which is exactly the API wrapped by System.Io.File. Copy.
>
Willy.
>
>
"Wayne" <me@nospam.comw rote in message
news:%23NNcWIcm IHA.1208@TK2MSF TNGP03.phx.gbl. ..
Willy,
>
This seems to work fine for me using Vista Pro. I have tried it on a
couple of different file types/applications (MS Word, AutoCAD, etc.) with
open files and this seemed to copy them anyway. The function returns a 1
and the file copy is created. I tried deleting the files and they are
definitely locked. No dice there. Perhaps this is a Vista phenomenon?
>
No, Vista behaves just like all other NT based OS version as far as File IO
goes..
None of the applications you mention do "lock" the files, nor do they keep
the files open when editing, with "locking" I mean open the file in
exclusive mode (not-shared), it's obvious that when you open a file for
shared read access that an other process can copy the file. Deleting a file
is a different matter, failure to delete is not due to the fact that the
file locked!
Try with a simple C# to open a file for read/write access with sharability
set to none and keep it open while you try to copy the file, you won't be
able to copy the file. Note that makes little sense to copy a file that is
open in another process, you are never guaranteed that the copy is logically
consistent. That's exactly why the shadow copy API's were invented.
"Wayne" <me@nospam.comw rote in message
news:%23NNcWIcm IHA.1208@TK2MSF TNGP03.phx.gbl. ..
>Willy,
>>
>This seems to work fine for me using Vista Pro. I have tried it on a
>couple of different file types/applications (MS Word, AutoCAD, etc.)
>with open files and this seemed to copy them anyway. The function
>returns a 1 and the file copy is created. I tried deleting the files
>and they are definitely locked. No dice there. Perhaps this is a
>Vista phenomenon?
>
No, Vista behaves just like all other NT based OS version as far as
File IO goes..
None of the applications you mention do "lock" the files, nor do they
keep the files open when editing, with "locking" I mean open the file
in exclusive mode (not-shared), it's obvious that when you open a
file for shared read access that an other process can copy the file.
Deleting a file is a different matter, failure to delete is not due
to the fact that the file locked!
But "locked" as you define it *is* the same mechanism that makes the files
undeletable:
CreateFile with SHARE_READ and without SHARE_DELETE -- The behavior
described by Wayne
CreateFile without SHARE_READ -- The behavior described by Willy, CopyFileEx
API won't work
What other explanation do you have for failure to delete, except that the
file is open without SHARE_DELETE?
Comment