Re: Unexpected failure mode...

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Hi Pegasus,

Pegasus [MVP] wrote:
"Neil Gould" <neil@xxxxxxxxxxxxxxxxx> wrote in message
news:O9FBVRhXKHA.508@xxxxxxxxxxxxxxxxxxxxxxx
Pegasus [MVP] wrote:
"Neil Gould" <neil@xxxxxxxxxxxxxxxxx> wrote in message
news:uTnnp8VXKHA.3612@xxxxxxxxxxxxxxxxxxxxxxx
Hi all,

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

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!

It was the local file system that got trashed, not the source file
system. I
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

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.

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



.

Relevant Pages

  • Re: Unexpected failure mode...
    ... my client decided to add files to the source folder that ... machine that the thumb drive was installed on (not the file system ... the installation of a financial application that the client doesn't ... I don't think there is anything unusual going on in the script, ...
    (microsoft.public.scripting.wsh)
  • Re: Unexpected failure mode...
    ... my client decided to add files to the source folder that ... machine that the thumb drive was installed on (not the file system ... the installation of a financial application that the client doesn't ... I don't think there is anything unusual going on in the script, ...
    (microsoft.public.scripting.wsh)
  • Re: folder permission is "read" only
    ... I notice the folder with the database I want to compact ... Generally the read-only attribute has no effect on folders - it does not prevent you from writing to a file contained in that folder. ... File attributes like Archive, Hidden, Read-Only and System are holdovers from the old FAT file system in DOS; they don't really apply to the NTFS file system. ... It's possible your script is failing because it cannot write to the database file - but if so, the cause while be somewhere else, rather than the Folder's attributes. ...
    (microsoft.public.windowsxp.general)
  • Re: Scanning multiple folders for files possible?
    ... It is easy to get VB Script to scan multiple folders but you need to be ... Scan every subfolder of the specified folder, ... specifying Unicode as the encoding ... Write a simple test script to use the file system ...
    (microsoft.public.scripting.vbscript)
  • Re: Running Access 97 Under XP
    ... installation, as recorded by the error in the installation log, ... Removing or correcting the Hatten font line in the installation ... script allowed the script to proceed to registration. ... a second folder with those same fonts, ...
    (comp.databases.ms-access)