(I am writing this in a way that other users who come across this answer can hopefully use it, not just the OP.)
There are multiple methods available for this kind of problem, as well as issues and trade-offs for each. Typically, you do no want a process running constantly that is using up all your CPU/RAM, or you won't be able to use the system!
You can write the code as a daemon, which will loop "forever", but in between iterations of the loop it will go idle/inactive/sleep so that other processes/programs get serviced as well. There are many things to be aware of in daemon mode, such as concurrency, race conditions, deadlocks, handling restarts if it exits unexpectedly, and even ensuring that you are not running the same daemon multiple times unless you do so intentionally and understand how to do it safely. I will not detail this further here--search the web for "writing daemons".
Another method is using various system monitoring tools that are triggered by system events such as new file creation, modification, access, and so on. This method also has some issues that can bring he system down if you do not understand how to use it safely. Likewise, I will not detail his method further here. Search for something "file system event notification" if this kind of method is the one you think would suit you best.
Yet another method (and there are still more ways) is to use the
cron daemon common to most (all?) un*x systems, to run a command or more likely a shell script periodically, such as once per minute. This method also has pitfalls, but they are usually easier to take steps to avoid. The biggest issue to adjust for is typically that your shell script (or powershell, or perl/pythen/other command/script) should be designed to process only once each time it is executed, not in an infinite loop. Let
cron deal with executing it again and again repeatedly (
cron itself is carefully designed to run as a daemon and handles all the details and many of he issues of of being a daemon, so you do not have to.) Once it is done processing, have it exit as soon as possible so the system and you can go back to doing other things, such as playing your favorite game. ;-)
Usually, the biggest issues you will need to be aware of with "cron jobs" are:
1: Set the intervals far enough apart to avoid overlap, and avoid repeatedly looping (especially infinite loops!) within the command/script. Otherwise, cron will start a new process even while the previous one is still looping. Before long, you will have hundreds or thousands of the same script running, looping, and colliding with each other, using up CPU, RAM, etc.
2: Related to the previous, you want your script to do--and finish--what it needs to do as quickly as possible, before
cron triggers the scrip to run again, as sated above. IF there is a chance two iterations will overlap (which may happen when copying a large file over the network, for example), you will need to plan for potential concurrency problems, deadlocks, etc. (Many scripts handle this by keeping track of the latest PID (process id) in a *.pid file, to detect if the previous iteration is still in progress and abort the "new" execution if the previous is still executing.)
3: Also related in this case, you will need to ensure that if multiple processes of the script do get triggered, only one of them does the copy operation. Othherise, they will clash with both trying to copy they exact same file/data. (This is why the *.pid method is used to abort when it detects that a previous execution has not yet completed. I leave the details of how to do all that as an exercise for the reader... to practice their searching and researching skills...)
4: The last issue you will probably need to account for is user access rights and permissions. The
cron tool runs in different modes--one is the system mode where the 'crontab' configuration needs to be told which user account to execute the command/script as and thus has that user account's permissions; And the other mode is per-user, where
cron already knows which user account to execute the command/script as because it is already implied. (Note that
cron does not execute the users
~/.bashrc or anything so you will need to include that in command/script if it is needed.)
There are other issues to be aware of in certain cases, so be certain to learn about them and how to deal with them when they occur. There is already a lot of information on
cron on the web, so I will not repeat it all here. Go search the web for it.
As a final note to he OP, I strongly suggest you learn to use the
rsync command if you can. It has a lot of options to control how/what it copies, detect if a file already exists, detect if one is older/newer than the other, and many more features you may find useful.