CopyFile's method side effect 
Author Message
 CopyFile's method side effect

If application keeps certain file locked, and script tries to copy that very file to some target location already containing one such file  (let's say copied there sometime before), copy operation fails (as expected, 'cause source file is locked), error object gets some numbering...

But in this process target destination gets zapped. Copy that was meant to be overwritten - disappears without a trace!  

Dim oFSO, sSrcFile, sDestFile
Set oFSO = CreateObject("Scripting.FileSystemObject")

sSrcFile = "C:\WINNT\Profiles\PetrovicB\Application Data\Microsoft\Outlook\Outlook.ost"
sDestFile = "D:\Saved\Application Data\Microsoft\Outlook\Outlook.ost"

On Error Resume Next
oFSO.CopyFile sSrcFile, sDestFile
    ' If Outlook is open, this fails, but sDestFile _gets_deleted_too_!?!

Interestingly this operation (on locked file) executes without errors:

Dim oFile
Set oFile = oFSO.GetFile(sSrcFile) ' sSrcFile is locked, but somehow that does not matter

Which means there is no way (or is it?) of testing if file is locked or not before trying copy-and-overwrite operation. Although kludgey workaround is possible, (like temporary renaming destination file, trapping error and then deleting it if everything goes smooth, or renaming it back if copy operation fails) I can not help but complain that all this is unneeded. If File System Object can not have a "firm grip" on source file it should not delete file it can "get its hands on" instead. Which brings me to this question:

Is there any direct VBS way (without trial-failure approach) of testing if certain file is locked or not?
Or if not locked - then if some application has this file opened or not?

Branimir



Tue, 05 Feb 2002 03:00:00 GMT  
 CopyFile's method side effect

I've seen similar post re: the inability to determine a file's locked status before with no good resolution.  One _possible_ way to do it is to open the source/destination (problem could be on either end) as textfiles ForAppending (with no intent to write to it) with an error trap.  Of course you'd also have to deal with the possiblity of read-only files...

<wishful-thinking>
Would be nice if the File object had a read-only Locked property!  Or the FSO had an FSO.IsLocked <filename> method.
</wishful-thinking>

--
Michael Harris

If application keeps certain file locked, and script tries to copy that very file to some target location already containing one such file (let's say copied there sometime before), copy operation fails (as expected, 'cause source file is locked), error object gets some numbering...

But in this process target destination gets zapped. Copy that was meant to be overwritten - disappears without a trace!  

Dim oFSO, sSrcFile, sDestFile
Set oFSO = CreateObject("Scripting.FileSystemObject")

sSrcFile = "C:\WINNT\Profiles\PetrovicB\Application Data\Microsoft\Outlook\Outlook.ost"
sDestFile = "D:\Saved\Application Data\Microsoft\Outlook\Outlook.ost"

On Error Resume Next
oFSO.CopyFile sSrcFile, sDestFile
    ' If Outlook is open, this fails, but sDestFile _gets_deleted_too_!?!

Interestingly this operation (on locked file) executes without errors:

Dim oFile
Set oFile = oFSO.GetFile(sSrcFile) ' sSrcFile is locked, but somehow that does not matter

Which means there is no way (or is it?) of testing if file is locked or not before trying copy-and-overwrite operation. Although kludgey workaround is possible, (like temporary renaming destination file, trapping error and then deleting it if everything goes smooth, or renaming it back if copy operation fails) I can not help but complain that all this is unneeded. If File System Object can not have a "firm grip" on source file it should not delete file it can "get its hands on" instead. Which brings me to this question:

Is there any direct VBS way (without trial-failure approach) of testing if certain file is locked or not?
Or if not locked - then if some application has this file opened or not?

Branimir



Tue, 05 Feb 2002 03:00:00 GMT  
 CopyFile's method side effect
Hi All,

 for some management reasons, it would even be a worthful
option to have the property ".OpenBy" .....

 Just my two cents.

Best regards,
Manfred Braun

(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany


(Remove the anti-spam-underscore to mail me!)

Quote:

>This is a multi-part message in MIME format.

>------=_NextPart_000_010D_01BEEAF0.22036110
>Content-Type: text/plain;
>    charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable

>I've seen similar post re: the inability to determine a file's locked =
>status before with no good resolution.  One _possible_ way to do it is =
>to open the source/destination (problem could be on either end) as =
>textfiles ForAppending (with no intent to write to it) with an error =
>trap.  Of course you'd also have to deal with the possiblity of =
>read-only files...

><wishful-thinking>
>Would be nice if the File object had a read-only Locked property!  Or =
>the FSO had an FSO.IsLocked <filename> method.
></wishful-thinking>

>--=20
>Michael Harris



>If application keeps certain file locked, and script tries to copy that =
>very file to some target location already containing one such file =
>(let's say copied there sometime before), copy operation fails (as =
>expected, 'cause source file is locked), error object gets some =
>numbering...=20
>=20
>But in this process target destination gets zapped. Copy that was meant =
>to be overwritten - disappears without a trace! =20

>Dim oFSO, sSrcFile, sDestFile
>Set oFSO =3D CreateObject("Scripting.FileSystemObject")
>=20
>sSrcFile =3D "C:\WINNT\Profiles\PetrovicB\Application =
>Data\Microsoft\Outlook\Outlook.ost"
>sDestFile =3D "D:\Saved\Application Data\Microsoft\Outlook\Outlook.ost"

>On Error Resume Next
>oFSO.CopyFile sSrcFile, sDestFile=20
>    ' If Outlook is open, this fails, but sDestFile =
>_gets_deleted_too_!?!

>Interestingly this operation (on locked file) executes without errors:

>Dim oFile
>Set oFile =3D oFSO.GetFile(sSrcFile) ' sSrcFile is locked, but somehow =
>that does not matter

>Which means there is no way (or is it?) of testing if file is locked or =
>not before trying copy-and-overwrite operation. Although kludgey =
>workaround is possible, (like temporary renaming destination file, =
>trapping error and then deleting it if everything goes smooth, or =
>renaming it back if copy operation fails) I can not help but complain =
>that all this is unneeded. If File System Object can not have a "firm =
>grip" on source file it should not delete file it can "get its hands on" =
>instead. Which brings me to this question:

>Is there any direct VBS way (without trial-failure approach) of testing =
>if certain file is locked or not?=20
>Or if not locked - then if some application has this file opened or not?

>Branimir

>------=_NextPart_000_010D_01BEEAF0.22036110
>Content-Type: text/html;
>    charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable

><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
><HTML><HEAD>
><META content=3D"text/html; charset=3Diso-8859-1" =
>http-equiv=3DContent-Type>
><META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
><STYLE></STYLE>
></HEAD>
><BODY bgColor=3D#ffffff>
><DIV>I've seen similar post re: the inability to determine a file's =
>locked=20
>status before with no good resolution.&nbsp; One _possible_ way to do it =
>is to=20
>open the source/destination (problem could be on either end) =
>as&nbsp;textfiles=20
>ForAppending (with no intent to write to it) with an error trap.&nbsp; =
>Of course=20
>you'd also have to deal with the possiblity of read-only files...</DIV>
><DIV>&nbsp;</DIV>
><DIV>&lt;wishful-thinking&gt;</DIV>
><DIV>Would be nice if the File object had a read-only Locked =
>property!&nbsp; Or=20
>the FSO had an FSO.IsLocked &lt;filename&gt; method.</DIV>
><DIV>&lt;/wishful-thinking&gt;</DIV>
><DIV><BR>-- <BR>Michael Harris</DIV>
><DIV>&nbsp;</DIV>
><DIV>&nbsp;</DIV>
><DIV>Branimir Petrovic &lt;<A=20

>message <A=20

>5</A>...</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>If application keeps certain =
>file locked,=20
>and script tries to copy that very file to some target location already=20
>containing one such file (let's say copied there sometime before), copy=20
>operation fails (as expected, 'cause source file is locked), error =
>object gets=20
>some numbering... </FONT></DIV>
><DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>But in this process target =
>destination gets=20
>zapped. Copy that was meant to be overwritten - disappears without a=20
>trace!&nbsp; </FONT></DIV>
><DIV>&nbsp;</DIV>
><DIV>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>Dim oFSO, sSrcFile, =
>sDestFile</FONT></DIV>
><DIV><FONT face=3D"Courier New" size=3D2>Set oFSO =3D=20
>CreateObject("Scripting.FileSystemObject")</FONT></DIV>
><DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>sSrcFile =3D=20
>"C:\WINNT\Profiles\PetrovicB\Application=20
>Data\Microsoft\Outlook\Outlook.ost"</FONT></DIV>
><DIV><FONT face=3D"Courier New" size=3D2>sDestFile =3D =
>"D:\Saved\Application=20
>Data\Microsoft\Outlook\Outlook.ost"</FONT></DIV>
><DIV>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>On Error Resume =
>Next</FONT></DIV>
><DIV><FONT face=3D"Courier New" size=3D2>oFSO.CopyFile sSrcFile, =
>sDestFile=20
></FONT></DIV>
><DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp; ' If Outlook =
>is open,=20
>this fails,&nbsp;but sDestFile _gets_deleted_too_!?!</FONT></DIV>
><DIV>&nbsp;</DIV>
><DIV>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>Interestingly this operation =
>(on locked=20
>file) executes without errors:</FONT></DIV>
><DIV>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>Dim oFile</FONT></DIV>
><DIV><FONT face=3D"Courier New" size=3D2>Set oFile =3D =
>oFSO.GetFile(<FONT=20
>face=3D"Courier New" size=3D2>sSrcFile</FONT>) ' sSrcFile is locked, but =
>somehow=20
>that does not matter</FONT></DIV>
><DIV>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>Which means there is no way (or =
>is it?) of=20
>testing if file is locked or not before&nbsp;trying copy-and-overwrite=20
>operation. Although kludgey workaround is possible, (like temporary =
>renaming=20
>destination file, trapping error and then deleting it if everything goes =
>smooth,=20
>or renaming it back if copy operation fails) I can not help but complain =
>that=20
>all this is unneeded. If File System Object can not have a "firm grip" =
>on source=20
>file it should not delete file it can "get its hands on" instead. Which =
>brings=20
>me to this question:</FONT></DIV>
><DIV>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" size=3D2>Is there any direct VBS way =
>(without=20
>trial-failure approach) of testing if certain file is locked or not?=20
></FONT></DIV>
><DIV><FONT face=3D"Courier New" size=3D2>Or if not locked - then if some =
>application=20
>has this file opened or not?</FONT></DIV>
><DIV>&nbsp;</DIV>
><DIV>&nbsp;</DIV>
><DIV><FONT face=3D"Courier New" =
>size=3D2>Branimir</FONT></DIV></BODY></HTML>

>------=_NextPart_000_010D_01BEEAF0.22036110--



Wed, 06 Feb 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. fso.CopyFile 'Permission Denied' Err

2. Problems with CopyFile Method

3. help on copyfile method

4. Part II - CopyFile Method

5. CopyFile Method Suggestions

6. Parameters of CopyFile-Method

7. copyfile method

8. problem using CopyFile method in remote script

9. CopyFile Method

10. Copyfile method using variables......

11. CopyFile Method problem

12. Modify registry doesn't take effect

 

 
Powered by phpBB® Forum Software