Mover tuning and 6.9
There's a few problems with this.
My original design used the existing script and simply called it appropriately based upon usage.
This method will still work but, the design of the plugin itself only checked for usage on the pool named "cache". The way that the mover script works is that once it's called, all cache pools get moved appropriately.
The work around for this is to modify the stock script so that another parameter can be issued which sets which cache pool to move, and only move that one. If you do the coding, LT would probably include the changes in the stock script. (No guarantees though)
Then in the plugin, you'd allow multiple schedules for each given pool and call the script accordingly.
The "new" plugin, also allows for movement of specific files based upon date (as I recall).
This would involve a rewrite / patch of the stock script to look for the dates, but also has the same problem as the above I would think.
If you do the coding via another parameter to the script, LT *may* (or may not) accept the changes. The key to any changes if you want it accepted is that the script still would have to operate identically if those extra parameters aren't specified.
You would also require to have the plugin selectively choose which of the versions of the script to replace it with. Either the 6.8 one or the 6.9 one depending upon the OS version.
Or, you can leave the script completely stock and forgo any of the date range options within the plugin and have it look at the pool named "cache" (or possibly another selectable pool to look at) for usage, and then the user has to accept that all pools will get moved.
Because of the multiple cache pool issues, with the plugin more or less replacing the stock script, unexpected results (ie: mover not working on other pools), I'm going to mark this plugin as incompatible with 6.9 until such time as @hugenbdd decides upon the direction this plugin should take.
(Or only having a single pool, but the pool isn't named "cache")
mover