xp_cmdshell default path (system32) problem

I'm trying to create some maintenance scripts that need to manage files in
some directories. I want to purge files that are older than a given number
of days. I'm use xp_cmdShell to execute "erase" command like commands to
delete the files. The problem I'm concerned about is related to the fact
that xp_cmdshell appears to use c:\WINNT\SYSTEM32 as it's default path.

I haven't executed the actual erase statements yet but rather have been
running test where I just perform a DIR instead of a ERASE to confirm what
WILL get deleted when I do it for real. The problem is, if the directory
that I supply doesn't exist, then the command appears to opporate on the
"default path". So for example if I do:

EXEC xp_cmdshell 'DIR c:\MyDir'

and "myDir" doesn't actually exist, then the xp_cmdShell is return the same
result set as if I executed:

EXEC xp_cmdshell 'DIR c:\WINNT\SYSTEM32'

This is more than a little scary since if I have had actually run this
command with ERASE instead of DIR then presumably it would have deleted all
file from the C:\WINNT\SYSTEM32 directory.... BAD THING!

Now, I can be REALLY, REALLY careful when I write my scripts to make sure I
use an existing directory. However, this doesn't protect me later when my
script is running as a scheduled job and some unssuspecting sole happens to
delete, rename or change the security settings on my directory and now the
next time the job runs I crush SYSTEM32!

There's got to be a better way to handle this... isn't there!?!

PLEASE HELP!



.

Relevant Pages

  • Re: basic command pipe question
    ... =>to erase a bunch of files in one go. ... will execute a seperate process for *EACH* file to be deleted and would potentially overflow before the for loop even starts. ... Although, if I understand properly what's happening here, the pipe solution allows files to be erased as they are found in the filelist, while the gobbing method first requires that all files that match be found, then each command is executed one after another. ...
    (Fedora)
  • Re: xp_cmdshell default path (system32) problem
    ... building a batch file in code and then ... it will NOT actually execute the delete if the patch I supply is not valid. ... I'm use xp_cmdShell to execute "erase" command like ...
    (microsoft.public.sqlserver.programming)
  • Re: xp_cmdshell default path (system32) problem
    ... I'm use xp_cmdShell to execute "erase" command like commands to delete the files. ... I haven't executed the actual erase statements yet but rather have been running test where I just perform a DIR instead of a ERASE to confirm what WILL get deleted when I do it for real. ... The problem is, if the directory that I supply doesn't exist, then the command appears to opporate on the "default path". ... However, this doesn't protect me later when my script is running as a scheduled job and some unssuspecting sole happens to delete, rename or change the security settings on my directory and now the next time the job runs I crush SYSTEM32! ...
    (microsoft.public.sqlserver.programming)
  • Re: xp_cmdshell default path (system32) problem
    ... I'm use xp_cmdShell to execute "erase" command like commands to delete the files. ... I haven't executed the actual erase statements yet but rather have been running test where I just perform a DIR instead of a ERASE to confirm what WILL get deleted when I do it for real. ... The problem is, if the directory that I supply doesn't exist, then the command appears to opporate on the "default path". ... However, this doesn't protect me later when my script is running as a scheduled job and some unssuspecting sole happens to delete, rename or change the security settings on my directory and now the next time the job runs I crush SYSTEM32! ...
    (microsoft.public.sqlserver.programming)
  • Re: xp_cmdshell default path (system32) problem
    ... I'm use xp_cmdShell to execute "erase" command like ... I haven't executed the actual erase statements yet but rather have been ... my script is running as a scheduled job and some unssuspecting sole ...
    (microsoft.public.sqlserver.programming)
Loading