Unexpected failure mode...
Neil Gould
XP, SP3
I installed a script to copy a folder from a network machine to a thumb
drive on a local machine, and it has been working reliably for about a year.
Recently, my client decided to add files to the source folder that resulted
in the folder size greatly exceeding the size of the thumb drive. The result
was that the WSH failure trashed the file system on the local machine that
the thumb drive was installed on (not the file system on the thumb drive,
btw)! The error message reported had nothing to do with the copy operation
according to MS (it was associated with the installation of a financial
application that the client doesn't have, nor was installing). I didn't see
any documentation or warnings about this possibility, so I thought I'd give
a "heads up" about this one. It was surprising, because even DOS failed in a
more "polite" way with an "out of space" error and no impact on the file
system.
--
Best,
Neil
Pegasus [MVP]
"Neil Gould" <ne...@myplaceofwork.com> wrote in message
news:uTnnp8VX...@TK2MSFTNGP02.phx.gbl...
It is extremely unlikely that the WSH failure thrashed the source file
system. Were you able to duplicate the event? If not then it's probably pure
coincidence that the system got thrashed when the target drive was full.
Unless, of course, there is something funny in your code - can't tell
without seeing it!
Neil Gould
was able to replicate the behavior multiple times in order to isolate and
determine that this problem exists. By "trashed", I mean that a "system
restore" was executed and that file read/write operations became erratic. I
expected a "drive is full" error with a more polite failure mode, but
nooooo...
I don't think there is anything unusual going on in the script, and it
worked for about a year until a folder with a lot of images was added by the
client, and it worked after cleaning up the system and using a large enough
thumb drive. But, here it is anyway:
-----------------------------------------------------------
Dim SFso, DDir, SDir, Msg, Outcome, CDN
Dim f, tmp, MObj
Set SFso = CreateObject("Scripting.FileSystemObject")
Set MObj = WScript.CreateObject("WScript.Shell")
On Error Resume Next
IF SFso.FileExists(tmp) Then
MObj.Popup "Backup is already running!",3,"Operation Closing",64
WScript.Quit
Else
CDN = WeekdayName(Weekday(Now()))
Msg = "Ready to begin backup for: " & CDN
Outcome = MsgBox(Msg, 1, "Backup Utility")
IF Outcome = 1 THEN
MObj.Popup "Backup is in progress... please wait",3,"Backup
Status",64
tmp = SFso.GetSpecialFolder(2)
tmp = tmp & ".\bkp.running"
Set f = SFso.OpenTextFile(tmp, 2, True)
SDir = "\\System_2\daily backup\" & CDN & "\Data"
DDir = "E:\"
SFso.CopyFolder SDir, DDir
IF Err.Number <> 0 THEN
DIM Emsg
IF Err.Description > "" THEN
Emsg = Err.Description
ELSE
Emsg = CStr(Err.Number)
END IF
Msg = "An error occurred during " & CDN & " backup operation"
& VbCrLF & "Error: " & Emsg & "... contact Neil!"
ELSE
Msg = CDN & " Backup Operation Completed Successfully"
END IF
f.Close
SFso.DeleteFile(tmp)
ELSE
Msg = "Backup has been cancelled"
END IF
END IF
Outcome = MsgBox(Msg, 0,"Result")
----------------------------------------------------------
--
Best,
Neil
Pegasus [MVP]
If you want to prevent your script from going off at a tangent when an error
occurs then you have two choices:
a) Set "on error resume next", then check the error code in each and every
spot where once could occur.
b) Set "on error goto 0" and allow the interpreter to terminate the script
whenever an error occurs.
Your script uses a mix of a) and b): It will continue no matter what error
occurs, except when an error occurs under the CopyFolder method. What about
errors elsewhere, e.g. here: Set f = SFso.OpenTextFile(tmp, 2, True)? The
usual solution consists of setting "on error resume next" just prior to the
CopyFolder method, then pick up the error code, then set "on error goto 0".
I suspect that this method will allow your code to deal with the error
gracefully and without thrashing any file system.
I also note that you're working with a file whose name is an uninitialised
variable called "tmp". Attempting to write to it or to check for its
existence would certainly cause an error condition, which your code ignores
because of the above reasons.
Neil Gould
When troublshooting the problem I removed the "On Error..." statement (SOP)
and the behavior was as described. Also, the problem was not "thrashing" of
the files system -- it did not "thrash", it was "_trashed_" by virtue of the
"System Restore" and the necessity to clean it up before read/write ops were
stabilized, even after a reboot. The script did not continue to run beyond
the extraneous error that was generated, according to Task Manager.
Thanks for taking a look, though, and I do appreciate your thoughts on this.
--
Best,
Neil