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