http://www.microsoft.com/technet/scriptcenter/csc/scripts/files/files/index.mspx
Plenty of scripts there to help. forfiles.exe /p (pathtofilestodelete) /s /m *.* /d -30 /�����cmd /c del /q @path��� A working example is: forfiles.exe /p d:\logs /s /m *.* /d -30 /c����cmd /c del /q @pa����� This will delete ALL files from d:\logs (and all sub folders it contains because /s has been used to force recursion) older than 30 days without prompting you to confirm deletion. Here is an explanation of the switches I used: /p = The path to search for the files you want to check the date of and remove /s = Recurse subdirectories contained within the path specified using /p and check them as well /m = The search mask to be used for the file type you want to check the date on (*.* being all files) /d = The date to compare the files against. A standard date type can also be used (dd/mm/yyyy) /c = The command to be used on a file that matches the /m and /d criteria /q = Used within /c to instruct the del command to delete files quietly Z Edward E. Ziots Network Engineer Lifespan Organization Email: [email protected] Phone: 401-639-3505 MCSE, MCP+I, ME, CCA, Security +, Network + -----Original Message----- From: Joe Fox [mailto:[email protected]] Sent: Tuesday, February 03, 2009 9:17 PM To: NT System Admin Issues Subject: Re: Del *.bak after 7 days This is the way that I used to do it on my last gig. It was a VBscript run as a Scheduled Task. <code> dtmDate = Date - 2 strDay = Day(dtmDate) If Len(strDay) < 2 Then strDay = "0" & strDay End If strMonth = Month(dtmDate) If Len(strMonth) < 2 Then strMonth = "0" & strMonth End If strYear = Year(dtmDate) strTargetDate = strYear & strMonth & strDay strComputer = "." Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2") Set FileList = objWMIService.ExecQuery _ ("ASSOCIATORS OF {Win32_Directory.Name='X:\SQL1\CAREMGMT'} Where " _ & "ResultClass = CIM_DataFile") For Each objFile In FileList strDate = Left(objFile.CreationDate, 8) If strDate < strTargetDate Then If objFile.Extension = "TRN" Or objFile.Extension = "BAK" Then objFile.Delete End If End If Next </code> HTH. -Joe On 2/3/2009 2:06 PM, Stefan Jafs wrote: > Thanks you are correct, I'll let SQL do it, however thanks for the > suggestions on "forfiles" and "delage32". > > ___________________________________ > Stefan Jafs > > > -----Original Message----- > From: Dennis Melahn [mailto:[email protected]] > Sent: Tuesday, February 03, 2009 1:55 PM > To: NT System Admin Issues > Subject: RE: Del *.bak after 7 days > > Lots of great ideas but Sam hit it on the head. Set your SQL Maintenance plan > to do this. I run incrementals on my Backup folder every night after the > Maintenance plan runs so I have my Maintenence Plan set to only keep 2 bak > files (that night and the previous night) for each DB. Why do extra work if > SQL will do it for you? > > Dennis > > > > > Curious, are these files part of a SQL Maintenance Plan? If so, the maint. > Plan should be parsing them I believe... > > > > From: Stefan Jafs [mailto:[email protected]] > Sent: Tuesday, February 03, 2009 10:32 AM > To: NT System Admin Issues > Subject: Del *.bak after 7 days > > > > I have a bunch of SQL back files th���������������s keep accumulating, they > are backed up to disk and then copied to tape, there is no need to keep more > that 7 days on the Hard drives. > > Does any one have a script / bat file that could del et *.bak from a folder > and subfolders after le����������s say 7 days? > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > > > This email and any attached files are confidential and intended solely for > the intended recipient(s). If you are not the named recipient you should not > read, distribute, copy or alter this email. Any views or opinions expressed > in this email are those of the author and do not represent those of the Amico > Corpoartion company. Warning: Although precautions have been taken to make > sure no viruses are present in this email, the company cannot accept > responsibility for any loss or damage that arise from the use of this email > or attachments. > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~<http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
