revDeleteFolder and Lessons Learned..

[Wouter]

Hi all,

Why patch revDeleteFolder with revDeleteFolderXXX?

Why not patch this backscript in a different way?
Like adding a param (and adapting the handler) :

  on revDeleteFolder pSrcFolder pWithoutWarning

which only will run in stealth mode if the pWithoutWarning is  
explecitely set to true.
(of course you must refrain from turning it on the first time you use  
it during development)
Older apps will still be able to use it, but only in warning mode.

Greetings,
Wouter



On 08 Jul 2005, at 12:03, Chipp Walters wrote:

> Hi Dave,
>
> Well, since I passed revDeleteFolder a single "/" and it tried to  
> delete (w/out being able to be interrupted) the *entire* hard disk,  
> I would say it's less dangerous to 'roll your own'. I would expect  
> revDeleteFolder to take as an argument a valid path, including  
> drive letter. For instance I would expect:
>
> revDeleteFolder "C:/"
>
> to delete the C drive. I don't know why just "/" does it and I'm  
> afraid to test it with a null, especially since it can't be  
> interrupted. Anything you roll on your own can be interrupted with  
> a control-period.
>
> The non-interruptibility of the command is a huge issue, IMO, and  
> one I'm not willing to take any more chances on. I haven't looked  
> at the code, but as Xavier mentioned, it seems like it should be an  
> engine level issue, not a shell call. You are certainly welcome to  
> use it to your hearts content-- I won't be. Once burned, twice shy.
>
> best,
>
> Chipp
>
> Dave Cragg wrote:
>
>
>> But I'm not entirely clear of the lesson to be learned. Is the   
>> problem really with revDeleteFolder, or with the nature of script   
>> locals?
>> If we don't use revDeleteFolder, but we want to delete a folder,  
>> then  we have to roll our own routines. This can be plenty  
>> dangerous too.
>>
>
>
>> So do we warn people not to use revDeleteFolder, and leave them  
>> to  their own potentially dangerous devices. Or simply warn people  
>> to be  *extremely* careful when deleting folders and check they  
>> are in fact  deleting the intended folder.
>>