EDIT: I'll try this way now... it apparently only downloads when mismatched and overwrites instead of adding a numeric extension keeping every version.
"wget -q -N -nH -P ./assets/<author>/ <url>"
leech_tool "v1.3"This one shouldn't redownload anything that's not been changed.
Bear in mind that this is unlikely to speedup the process in a great amount as "checks" (protocol chit chat) sometimes take more bytes than redownloading a small file.
When running Wget with `-N', with or without `-r', the decision as to whether or not to download a newer copy of a file depends on the local and remote timestamp and size of the file (see section 5. Time-Stamping). `-nc' may not be specified at the same time as `-N'.
leech_tool "v1.2c" WITH CONTINUING
But take heed...On the other side of the coin, while using `-c', any file that's bigger on the server than locally will be considered an incomplete download and only (length(remote) - length(local)) bytes will be downloaded and tacked onto the end of the local file. This behavior can be desirable in certain cases--for instance, you can use `wget -c' to download just the new portion that's been appended to a data collection or log file.
However, if the file is bigger on the server because it's been changed, as opposed to just appended to, you'll end up with a garbled file. Wget has no way of verifying that the local file is really a valid prefix of the remote file. You need to be especially careful of this when using `-c' in conjunction with `-r', since every file will be considered as an "incomplete download" candidate.
Another instance where you'll get a garbled file if you try to use `-c' is if you have a lame HTTP proxy that inserts a "transfer interrupted" string into the local file. In the future a "rollback" option may be added to deal with this case.
Note that `-c' only works with FTP servers and with HTTP servers that support the Range header.