# Need DOS batch to copy files from yesterday



## DarkBeer (Jul 21, 2010)

I have a directory that has a month's worth of PDF files in it. I need an automated batch file that can be run each night to copy all of the PDF files with yesterday's date on the file stamp to another directory. I have a scheduler that will run this batch just after midnight each night. So something that copies *.PDF from directory 1 to directory 2 where date is today minus 1 day.
Thanks for any help!


----------



## TheOutcaste (Aug 8, 2007)

Welcome to TSG!

What OS will this be run under?
Do you have either Forfiles.exe or Robocopy.exe?
Are you checking the date using the Modified date, or the Created date?


----------



## ghostdog74 (Dec 7, 2005)

download coreutils and findutils, then do this


```
C:\test>gnu_find.exe . -type f -mtime +1 -exec cp "{}" c:\tmp ;
```


----------



## DarkBeer (Jul 21, 2010)

Sorry for the delayed response. Running on Windows XP and working from the modified date.


----------



## DarkBeer (Jul 21, 2010)

Downloaded coreutils and findutils, but don't have gnu_find.exe. Substituted find.exe, but didn't work with the arguments you provided.



ghostdog74 said:


> download coreutils and findutils, then do this
> 
> 
> ```
> ...


----------



## DarkBeer (Jul 21, 2010)

Renamed the find.exe from the Gnu package to gnu_find.exe and it worked. with " -mtime +1" it copied everything, so I changed it to "-mtime -1" assuming that would do 1 day ago. It actually does 24 hours ago. It copied everything from 24 hours ago (2pm) to current, not just files created yesterday. I suppose this would be okay if I run it at 1 second past midnight.


----------



## Squashman (Apr 4, 2003)

Because the Windows CMD line has a FIND program built-in you needed to rename the GNU find. Has a bit more functionality then the latter. I think ForFiles would be a better option though.


----------



## ghostdog74 (Dec 7, 2005)

Squashman said:


> Has a bit more functionality then the latter.


not a bit, but a whole lot more. 



> I think ForFiles would be a better option though.


how is forfiles better ? it would be educational if you could elaborate on that.


----------



## Squashman (Apr 4, 2003)

ghostdog74 said:


> not a bit, but a whole lot more.


That is why FINDSTR was created. It doesn't do time evaluations but is a whole lot better than FIND.



> how is forfiles better ? it would be educational if you could elaborate on that.


Not going to get into a contest on which is better and why. I am all for using the right tool for the right job. When a native command can be used to do the task then I think that is the better option for portability purposes.


----------



## ghostdog74 (Dec 7, 2005)

Squashman said:


> That is why FINDSTR was created. It doesn't do time evaluations but is a whole lot better than FIND.


if you mean the windows own find command, then yes. Its a bit better. However, GNU's find command is not a tool to find strings in text files. Its not the same as windows find or findstr. To find strings in files, grep/awk/sed all does the job better than findstr/find.



> When a native command can be used to do the task then I think that is the better option for portability purposes.


forfiles is not native (at least for XP and below), thus so much for portability. forfiles also doesn't work in *nix. Therefore, another issue for portability. common usage of GNU find can both work in *nix and windows.


----------



## Squashman (Apr 4, 2003)

I would like to see you take 99% of the batch files that myself or anyone else has written on these forums and replace find/findstr with GREP/awk/sed and still see if they are portable. Its not going to happen because the syntax is still different for FOR loops. Variables are defined differently and string substitution and replacement is done differently. Lets not get started with calling subroutines.

I am all for using Unix utilities when needed. I know I have told you in the past that is my background from many years ago. In a business environment, Forfiles and Robocopy are going to be more common then trying to roll out your GNU pkgs to a couple thousand desktops.


----------



## ghostdog74 (Dec 7, 2005)

Squashman said:


> I would like to see you take 99% of the batch files that myself or anyone else has written on these forums and replace find/findstr with GREP/awk/sed and still see if they are portable. Its not going to happen because the syntax is still different for FOR loops. Variables are defined differently and string substitution and replacement is done differently. Lets not get started with calling subroutines.


well, i would not write it with batch in the first place. Cross platform languages like Python /Perl is what i recommend for production. 


> I am all for using Unix utilities when needed. I know I have told you in the past that is my background from many years ago. In a business environment, Forfiles and Robocopy are going to be more common then trying to roll out your GNU pkgs to a couple thousand desktops.


whether its forfiles/robocopy or GNU tools, whenever these are downloaded, its only a 1 time effort. Furthermore, GNU tools are just .exe files when installed. They can be kept in portable media and brought anywhere. If one has the technology, they can be pushed down to PCs effortlessly.


----------



## Squashman (Apr 4, 2003)

ForFiles and Robocopy are native to Windows Vista and above. And now the PowerShell is in by default with Windows 7 and can also be installed on XP and Vista.

With python and perl you still need to install the interpreter.

I would rather keep it simple. Pushing things down to PC's isn't always as easy as you think. That is dependent on how the network is setup.


----------



## ghostdog74 (Dec 7, 2005)

Squashman said:


> ForFiles and Robocopy are native to Windows Vista and above. And now the PowerShell is in by default with Windows 7 and can also be installed on XP and Vista.


that's right. they are not everywhere as well. you still need to install them if you are going to use them on older machines.



> With python and perl you still need to install the interpreter.


no need to. There are compilers to convert them to standalone if needed, and the converters are pretty reliable as well. Plus, if i ever want to change environment to say, linux, my script can still work without much changes.


----------



## TheOutcaste (Aug 8, 2007)

Do you want to *copy* the files, leaving them in the source folder, or *move* the files?
Is the destination always going to be the same folder, or are you sorting files into different folders for each day?

If you want to copy files dated yesterday *and earlier*, into the same folder, you can use this:

```
@Echo Off
Set _Source=C:\Test Source
Set _Dest=C:\Test Dest\
Forfiles /D -1 /P "%_Source%" /M *.PDF /C "cmd /c XCopy /CD @path 0x22%_Dest%0x22"
```
If you run this at Noon, it will not copy files modified today at 8 AM for example, but will copy the ones modified yesterday at 8 AM
Files modified 2 days ago, or older, will also be copied. If the destination is the same folder each day this won't be a problem, and the files won't be copied if they already have been copied, so no extra network bandwidth will be used if the destination is a network share.
If you miss a day, this will get the missed files when it is run.

If you are putting the files from each day into a *different* folder, it gets a little more complex:
This will only copy files with yesterday's date, and *not* the day before or earlier.

```
@Echo Off
Set _Source=C:\Test Source
Set _Dest=C:\Test Dest\
Set _Tmp=%temp%\0.0
If Exist "%_Tmp%" Del "%_Tmp%"
For /F "Tokens=* Delims=" %%I In ('Forfiles /D -2 /P "%_Source%" /M *.cmd /C "cmd /c Echo @path"') Do Echo.%%~I>>"%_Tmp%"
For /F "Tokens=* Delims=" %%I In ('Forfiles /D -1 /P "%_Source%" /M *.cmd /C "cmd /c Echo @path"^|Findstr /I /V /L /G:"%_Tmp%"') Do XCopy /CD "%%~I" "%_Dest%"
If Exist "%_Tmp%" Del "%_Tmp%"
```
Forfiles used to be able to do (today-n) and newer, but they broke that when they updated it. Now it's (Today-n) and older, or (Today*+*n) and newer. I don't see the utility of searching for files dated in the future...


----------

