View Full Version : Deleting Files
Faydra
2nd July 2009, 09:58 AM
I need some kind of Windows utility or script that will, given a directory as input, go down into each subdirectory of the given path and delete all files older than x amount of days. If it could be automated even better.
I could write this script in unix in my sleep, but Windows and I don't get along. Any ideas would be appreciated. Thanks!
Cayvmann
2nd July 2009, 11:03 AM
If you know and like Unix, you could download Cygwin and use the shell provided, and write that script in bash ( i think ). Otherwise you could learn Perl or another portable language and use that as your script language of choice.
Faydra
2nd July 2009, 01:06 PM
Hmmm... now that you mention cygwin I think that's actually already on the box. I'll check that out! Thanks!
jsiv
2nd July 2009, 01:07 PM
Do you have Microsoft PowerShell (http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx) installed (or an OS with it bundled)?
Everyone should have it, it's basically the successor to the old command line.
To recursively list all files modified earlier than 30 days ago starting in the current directory, you would start with doing a recursive listing:
gci -r (get-childitem -recurse)
Then you could filter the output from this with where (where-object):
where {$_.lastwritetime -lt (get-date).addDays(-30)}
In other words, select all objects where the last write time is less than the current date minus 30 days. If you wanted to do the opposite and delete all files modified in the last 30 days, you'd just replace the -lt with -gt (greater than). There's also things like -le (less or equal), -ge (greater or equal), -eq (equal), etc.
Finally, you'd pipe this to the remove-item command (ri or rm for short) to get this full command:
gci -r|where {$_.lastwritetime -lt (get-date).addDays(-30)}|ri
or
ls -r|where {$_.lastwritetime -lt (get-date).addDays(-30)}|rm for a slightly more unixy feel.
laca
2nd July 2009, 01:13 PM
ls -r|where {$_.lastwritetime -lt (get-date).addDays(-30)}|rm
Oh dear, Microsoft have waited 20 years or so and still couldn't do it better or at least at the same level as unix did it 20 years ago...
godless dave
2nd July 2009, 01:14 PM
This is the kind of thing I do at work. It is possible in Windows. If I get motivated I'll write a batch program for you.
jsiv
2nd July 2009, 01:20 PM
Oh dear, Microsoft have waited 20 years or so and still couldn't do it better or at least at the same level as unix did it 20 years ago...
How would you design the same in a generic way?
jsiv
2nd July 2009, 02:44 PM
This is the kind of thing I do at work. It is possible in Windows. If I get motivated I'll write a batch program for you.
I don't think it's really practical to make a batch script that does it, but I'd like to see it done.
PowerShell is the most elegant. VBScript might win because it's available on more systems than PS, but it's nowhere near as elegant. The same there would be something like this:
if wscript.arguments.count <> 2 then
wscript.quit
end if
Set fs = createobject("scripting.filesystemobject")
Set dir = fs.getfolder(wscript.arguments.item(1))
days = cint(wscript.arguments.item(0))
for each f in dir.files
if datediff("d", f.datelastmodified, now) > days then f.delete
next
Used as deleteolderthan.vbs <days> <path>
laca
3rd July 2009, 03:17 AM
How would you design the same in a generic way?
I wouldn't. Others much brighter than myself have done it decades ago, so I would avoid reinventing the wheel and make it in the process square-y ;)
Wudang
3rd July 2009, 03:23 AM
I'd go for the VBscript option for the same reason I use vi on unix.
I can count on it being available
jsiv
3rd July 2009, 03:36 AM
I wouldn't. Others much brighter than myself have done it decades ago, so I would avoid reinventing the wheel and make it in the process square-y ;)
This is just a dumb "M$ SUXX" post. Yes, you could have ported find, but the difference between that and the command line I gave is that mine acts on generic data. It could be acting on any type of data from any location with any properties, not just the file system. It is extremely powerful. If this kind of deleting is something you do often, just stick the command line in a script called dot (get it, delete older than).
If people like you had their way, there would be no diversity at all. Already we are pretty much down to only two architectures -- Unix-inspired and Windows.
laca
3rd July 2009, 03:43 AM
This is just a dumb "M$ SUXX" post.
I did not say "M$ SUXX" anywhere in my post. I referred to the cumbersomness of the given command line.
Yes, you could have ported find, but the difference between that and the command line I gave is that mine acts on generic data. It could be acting on any type of data from any location with any properties, not just the file system. It is extremely powerful. If this kind of deleting is something you do often, just stick the command line in a script called dot (get it, delete older than).
It might be powerful, but it is clearly not the right tool for the given job.
If people like you had their way, there would be no diversity at all. Already we are pretty much down to only two architectures -- Unix-inspired and Windows.
No need for name-calling and categorizing. You don't know me. Please abstain from rash conclusions.
Oliver
3rd July 2009, 04:08 AM
Uhm, while Windows file management certainly sucks, it's quite easy to search for files within a certain range of dates. So it's actually easy to delete all files written between February 10, 2008 to March 9, for example.
Here's how the extended search window looks like in XP:
http://www.adammathes.com/academic/search-engines/desktop/xp-advanced-searching.png
For more details:
http://www.microsoft.com/windows/products/winfamily/desktopsearch/technicalresources/advquery.mspx
jsiv
3rd July 2009, 04:45 AM
It might be powerful, but it is clearly not the right tool for the given job.
Nonsense. It's just the right tool for the job. If you absolutely must have 3000 different commands that do very specific things, just echo it into sdf.ps and you're done. It's so beyond absurdly simple that there isn't even anything to argue about other than "it's different than 'Unix'".
nathan
3rd July 2009, 04:48 AM
pah! use zsh
rm **/*(.m+5)
(for every regular file not modified in the last 5 days)
Ducky
3rd July 2009, 05:07 AM
pah! use zsh
rm **/*(.m+5)
(for every regular file not modified in the last 5 days)
That's a scary command. I would hope in the script you use it in it has sanity checking not to delete system files...
laca
3rd July 2009, 05:09 AM
Nonsense. It's just the right tool for the job. If you absolutely must have 3000 different commands that do very specific things, just echo it into sdf.ps and you're done. It's so beyond absurdly simple that there isn't even anything to argue about other than "it's different than 'Unix'".
Just look at that command line...
pah! use zsh
rm **/*(.m+5)
(for every regular file not modified in the last 5 days)
... and then at this one... Thanks nathan.
All I'm saying that it is more cumbersome, not that it isn't powerful or it cannot be automated. I'm sure a well versed professional can do wonders with it.
Oliver
3rd July 2009, 05:14 AM
Guys, all the nerd stuff probably won't help the thread starter.
The easiest way is to use the familiar search function of Windows, specify the folder you'd like to search for the files and add a period of time when the files were saved. After doing so, all he has to do is to delete all files that came up within the search-results...
Case solved.
Ducky
3rd July 2009, 05:18 AM
Guys, all the nerd stuff probably won't help the thread starter.
The easiest way is to use the familiar search function of Windows, specify the folder you'd like to search for the files and add a period of time when the files were saved. After doing so, all he has to do is to delete all files that came up within the search-results...
Case solved.
If the OP can "write this in unix" in their sleep, I'd venture a guess that "all the nerd stuff" is not lost on them.
Oliver
3rd July 2009, 05:21 AM
If the OP can "write this in unix" in their sleep, I'd venture a guess that "all the nerd stuff" is not lost on them.
Concerning Windows, it obviously seems to be the case. So why not presenting the easiest solution using the parts of Windows he most probably is familiar with anyway. In other words: "Programmers: It never can be complicated enough to solve an easy problem." :D :p
Ducky
3rd July 2009, 05:23 AM
Concerning Windows, it obviously seems to be the case. So why not presenting the easiest solution using the parts of Windows he most probably is familiar with anyway. Programmers: It never can't be too complicated to solve a problem. :D :p
unix folk != programmers.
While possibly related (really depends on function), they are not the same.
That said, I agree that the easiest solution is probably the best choice. That doesn't mean the average person who knows much for one OS isn't above or unable to learn about another OS via posts such as these.
laca
3rd July 2009, 05:23 AM
The easiest way is to use the familiar search function of Windows, specify the folder you'd like to search for the files and add a period of time when the files were saved. After doing so, all he has to do is to delete all files that came up within the search-results...
Case solved.
Not if it has to be automated.
Ducky
3rd July 2009, 05:25 AM
Not if it has to be automated.
Ok, I'm not disagreeing here, just asking:
Surely you can automate an API call to the search function? (NOTE: not suggesting this is the easiest way.)
jsiv
3rd July 2009, 05:26 AM
Well laca, Windows is inspired by an OS where even changing the current directory is an eleven letter command, so if you want it that condensed you just have to make your own aliases or one-line scripts. It's a compromise between flexibility and brevity.
And you can automate the Explorer search with PS or VBScript, but then the question becomes what the point is when you can just perform the action directly from either one.
Ducky
3rd July 2009, 05:30 AM
And you can automate the Explorer search with PS or VBScript, but then the question becomes what the point is when you can just perform the action directly from either one.
This is the answer I was looking for. Thanks.
Purely an intellectual problem on my part. I don't run windows machines (and before I get flamed for being an Apple fanboy, I don't run OS X either. For that matter, I don't even run Linux.)
ETA:
(Whoops, not entirely true. I do have one apple machine I haven't replaced yet.)
laca
3rd July 2009, 06:03 AM
Well laca, Windows is inspired by an OS where even changing the current directory is an eleven letter command, so if you want it that condensed you just have to make your own aliases or one-line scripts. It's a compromise between flexibility and brevity.
I'm not sure I understand what you mean by "Windows is inspired by an OS...", but other than that, agreed.
And you can automate the Explorer search with PS or VBScript, but then the question becomes what the point is when you can just perform the action directly from either one.
Again, agreed.
ddt
3rd July 2009, 10:29 AM
As a Unix guy, I have to give a thumbs-up to MS for their PowerShell:
gci -r|where {$_.lastwritetime -lt (get-date).addDays(-30)}|ri
or
ls -r|where {$_.lastwritetime -lt (get-date).addDays(-30)}|rm for a slightly more unixy feel.
This is a cool command-line, IMHO. The thing that laca is missing, I guess, is that the PowerShell is more powerful than a standard Unix shell. The pipes pass objects around, which can have all kinds of properties - whereas a Unix pipe only passes lines of text around. You'll notice the difference when you need, later on in your pipe, say, both the name of a file and its last-modification-time.
Not that I'm very knowledgeable in the PowerShell, only read some introductory articles about it - sorry, too much time already needed to keep up in Unix, Perl, Java, etc... But it certainly is on my list of "interesting things to fiddle with when I have the time". It's only too bad that Microsoft came to the realisation that the command-line is important so very late.
Well laca, Windows is inspired by an OS where even changing the current directory is an eleven letter command, so if you want it that condensed you just have to make your own aliases or one-line scripts. It's a compromise between flexibility and brevity.
I'm at a loss which OS you're alluding to. Care to enlighten me?
GreNME
3rd July 2009, 11:03 AM
unix folk != programmers.
While possibly related (really depends on function), they are not the same.
Thank you. I'm really not bad on *nix machines, but I would never, ever, ever consider myself a programmer. I'm a hack, with a little bit of hacker, who has learned the versatility of scripting. I couldn't program my way out of a wet paper bag on a serious development project.
-----
This is the answer I was looking for. Thanks.
Purely an intellectual problem on my part. I don't run windows machines (and before I get flamed for being an Apple fanboy, I don't run OS X either. For that matter, I don't even run Linux.)
ETA:
(Whoops, not entirely true. I do have one apple machine I haven't replaced yet.)
Sun fanboy!
As what essentially amounts to a Windows desktop management and server admin (throw in some departmental governance in there as well), I can verify that in most given cases the most elegant solution for scripting is going to involve some VBScript and WMI calls. That's going to change some with PowerShell in Win 7 as it comes out-- and already is a powerful command-line addition to Exchange 2007-- but for dealing with the widest possible array of capabilities in a Windows network VBScript really is the quickest and easiest way to smartly get the job done (as opposed to batch).
jsiv
3rd July 2009, 11:24 AM
I'm at a loss which OS you're alluding to. Care to enlighten me?
It was a joke, really. The Windows kernel is inspired by VMS, and cd on VMS is "set default".
laca
3rd July 2009, 12:55 PM
As a Unix guy, I have to give a thumbs-up to MS for their PowerShell:
This is a cool command-line, IMHO. The thing that laca is missing, I guess, is that the PowerShell is more powerful than a standard Unix shell. The pipes pass objects around, which can have all kinds of properties - whereas a Unix pipe only passes lines of text around. You'll notice the difference when you need, later on in your pipe, say, both the name of a file and its last-modification-time.
OK, I will say it once more: I never said it wasn't powerful. I said it was too cumbersome for this specific task. This task did not require the ability to pass objects around in the pipe.
On a sidenote, why can't one pass objects around in text? The fact that I know of no *nix program that iscapable of doing it does not mean it is impossible.
Wudang
3rd July 2009, 01:06 PM
but for dealing with the widest possible array of capabilities in a Windows network VBScript really is the quickest and easiest way to smartly get the job done (as opposed to batch).
And if you learn VBScript you're not that far away from VBA which can be quite handy.
vexed
3rd July 2009, 01:13 PM
I need some kind of Windows utility or script that will, given a directory as input, go down into each subdirectory of the given path and delete all files older than x amount of days. If it could be automated even better.
I could write this script in unix in my sleep, but Windows and I don't get along. Any ideas would be appreciated. Thanks!
Purger.exe (http://www.download25.com/install/purge.html)
ddt
4th July 2009, 06:07 AM
OK, I will say it once more: I never said it wasn't powerful. I said it was too cumbersome for this specific task. This task did not require the ability to pass objects around in the pipe.
Fair enough. In this case, Unix 'find' indeed can do all the selections you need in one go.
On a sidenote, why can't one pass objects around in text? The fact that I know of no *nix program that iscapable of doing it does not mean it is impossible.
Yes, of course you can pass around anything in Unix pipes. My wording was a bit careless. The Unix toolbox consists of tools which all operate on the concept of "lines of text", so if you pass around things that do not adhere to that concept, you're lost. Filenames with a newline in it - though fine to the Unix kernel - are a pain in the ass when it comes to scripting. GNU find with '-print0' and GNU xargs with the '-0' option only partially alleviate that problem.
GreNME
4th July 2009, 10:41 AM
Yeah, you can pass objects around in the *nix command line pretty easy. I don't get where the impression it was otherwise came about.
jsiv
4th July 2009, 10:53 AM
There's no generic way. You could come up with your own private way of serializing the data, but then only other programs made by you would be able to use them.
laca
4th July 2009, 01:14 PM
There's no generic way. You could come up with your own private way of serializing the data, but then only other programs made by you would be able to use them.
That is not an argument, since I think there is no generic way of passing a program data in a format it doesn't expect on any OS.
ddt
4th July 2009, 07:18 PM
That is not an argument, since I think there is no generic way of passing a program data in a format it doesn't expect on any OS.
The whole point is:
- the Unix toolbox is built around the concept of data organized as lines of text.
- the PowerShell toolbox is built around the concept of data organized as objects.
So if you want to have the functionality of PowerShell on Unix/Linux, you'd have to make the appropriate toolbox. Actually, someone is already doing that (http://pash.sourceforge.net/).
GreNME
4th July 2009, 11:32 PM
So if you want to have the functionality of PowerShell on Unix/Linux, you'd have to make the appropriate toolbox. Actually, someone is already doing that (http://pash.sourceforge.net/).
Hey, that's totally badass. It would make running administrative tasks from a *nix or Mac machine a breeze, provided the servers are Win Server 2008 and later and the clients Vista/Win 7 and later. Provided that they manage to allow the implementation to pass commands in the other direction, it also allows for adding greater ability to integrate *nix and Mac machines into an Active Directory infrastructure with less need for 3rd party crap or separate script repositories.
laca
5th July 2009, 02:23 AM
The whole point is:
- the Unix toolbox is built around the concept of data organized as lines of text.
- the PowerShell toolbox is built around the concept of data organized as objects.
So if you want to have the functionality of PowerShell on Unix/Linux, you'd have to make the appropriate toolbox. Actually, someone is already doing that (http://pash.sourceforge.net/).
Yes, that was mainly my point also. Thanks for the link.
moopet
6th July 2009, 03:45 PM
This is a cool command-line, IMHO. The thing that laca is missing, I guess, is that the PowerShell is more powerful than a standard Unix shell. The pipes pass objects around, which can have all kinds of properties - whereas a Unix pipe only passes lines of text around. You'll notice the difference when you need, later on in your pipe, say, both the name of a file and its last-modification-time.
I have done no research on this at all, and haven't tried PowerShell, but I''m curious as to why you think it's a benefit to pass said object. Is there a better/different example of what MS considers an object, or an interface that is usable by regular programs? For instance, what if you pass an object to a program which doesn't understand them?
If you normalise the data passed, which makes sense, it seems pointless.
I mean, I wouldn't pass a printing command a string, the length of that string and the number of instances of the letter 'S' in that string all as an object, because all of that information is resolvable from the string itself. I wouldn't pass a filename and the file's metadata to another program because I cannot control how long it is before that program executes, when the metadata might have changed. It should be resolved from one unique identifier. In *nix this is often the filename. Is there any instance you can think of that I obviously haven't where passing information resolvable from the filename in addition to the filename would be of any use?
I could google the answer to all this, but so could the OP, and anyway you sould like you could give me a more specific answer.
© 2001-2009, James Randi Educational Foundation. All Rights Reserved.
vBulletin® v3.7.7, Copyright ©2000-2012, Jelsoft Enterprises Ltd.