Re: Unexpected failure mode...

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


"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.


.

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)